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(54) Digital data copyright protection system 

(57) A digital data copyright protection system 
especially for unencrypted data to protect a copyright 
thereof while charging a user appropriate royalties 
therefor In the digital data copyright protection system, 
super distribution data Is received by a super distribu- 
tion data receiving unit (401) for storage in a super dis- 
tribution data storage region (402). Right management 
information is acquired by an RMI acquiring unit (403) 
for storage in an RMI storage region (404). Unencrypted 
data is read by a data reading unit (406), encrypted by 
a data encrypting unit 408 with a key extracted by a con- 
tent key extracting unit 405, and then is provided with 
the right management Information in an RMI adding unit 
(409) for storage. Once the data is through with a pur- 
chase processing in a purchase processing unit (412), 
the data is decrypted by the content decrypting unit 

(414) , and is played back by a reproduction control unit 

(415) and a speaker (41 6), or provided with an ID stored 
in a user ID storage region (41 8) by a distributor ID add- 
ing unit (41 1) for output. 



P I G. 1 




FIRSr DICHAL 




tHOA SOOBUIC 




M> EQWRJCDC 









SON) DIGZUL 

MT A apoatn c 

AID ksnuJUkuC 



AID 
APPAB&nS 



Printed by Xerox (UK) Business Services 
2.18.7 (HRS)/3.6 



1 



EP 1 089 241 A2 



2 



Description 

BACKGROUND OF THE INVENTION 
Field of the Invention 

[0001] The present invention relates to digital data 
copyright protection systems and, more specifically, to a 
system for protecting a copyright of music data while 
charging a user appropriate royalties therefor. 

Description of the Background Art 

[0002] In recent years, CDs (Compact Disc) have 
been popular media for music. Such CD is easy to carry, 
and thus people feel free to hand their CDs to others to 
let them try. Such hand-to-hand music distribution often 
contributes to mega hit Problem herein is that the CD is 
hardly protected against piracy, that is. unauthorized 
copying. Further, such CD is copied with ease into a 
CD-R (Compact Disc Recordable) which recently 
became commercially available. MDs (Mini Disc) are 
also becoming popular as media for music data previ- 
ously recorded in the CDs. Music data is thus easily 
copied thereby, and if the music data is shared beyond 
the scope of the copyright law, the copyright holders suf- 
fer. 

[0003] In order to prevent such easy copying, dis- 
closed in Japanese Patent Laid-Open Publication No. 9- 
34841 (97-34841) is a conventional system for encrypt- 
ing CDs before distribution, transmitting a decryption 
key over a network, and billing therefor. As such, online 
music distribution and billing over the network is quickly 
becoming popular. 

[0004] With such conventional system, however, 
online music distribution and billing is personalized one- 
on-one, and thus music data is not expansively distrib- 
uted among users as with the hand-to-and distribution 
workable for CDs. So far, facilitating the distribution of 
music data has not been an issue for online music dis- 
tribution. 

SUMMARY OF THE INVENTION 

[0005] Therefore, an object of the present invention 
Is to provide a copyright protection system especially for 
online music distribution, implementing protection for a 
copyright of music data by charging appropriate royal- 
ties therefor, and facilitating the distribution of the music 
data. 

[0006] The present invention has the following fea- 
tures to attain the object above. 
[0007] A first aspect of the present invention is 
directed to a digital data copyright protection system for 
charging a user appropriate royalties while protecting a 
copyright of digital data, the system comprising: 

a content distribution unit operable to distribute 



super distribution data including the digital data 
over a network: 

a plurality of digital data recording and reproducing 
apparatuses interconnected via the network, each 

5 capable of storing the super distribution data 

received from the content distribution unit, repro- 
ducing the digital data, and distributing the super 
distribution data stored therein to the others; and 
a billing processing unit operable to communicate 

10 with the digital data recording and reproducing 
apparatuses over the network, and go through a 
billing processing for charging the royalties, 
wherein 

the digital data recording and reproducing appara- 
15 tuses each 

communk^ate, prior to reproducing the digital 
data, with the billing processing unit to go 
through a purchase processing to be ready for 
20 the billing processing when receiving the super 

distribution data from the content distribution 
unit or the other digital data recording and 
reproducing apparatuses over the network, 
and 

25 add, prior to distribution, a distributor ID to the 

super distribution data received from the con- 
tent distribution unit or the other digital data 
recording and reproducing apparatuses over 
the network, wherein, 

30 

when the super distribution data subjected to the 
billing processing is provided with the distributor ID, 
the billing processing unit goes through a bonus 
processing with respect to a user identified by the 
35 distributor ID. 

[0008] As described above, in the first aspect, pro- 
vided is a digital data copyright protection system capa- 
ble of protecting a copyright while charging a user 
40 appropriate royalties, and benefiting a copyright holder 
to a greater extent by using bonus to lure the user to dis- 
tribute the data. 

[0009] A second aspect of the present invention is 
directed to a digital data recording and reproducing 

45 apparatus being capable of storing super distribution 
data including a content which is digital data encrypted 
under a first system and right management infonmation 
having a content key used for the first system, and of 
reproducing the content after going through a purchase 

50 processing to be ready for a billing processing by com- 
municating with a billing processing unit connected via a 
network, the apparatus comprising: 

a super distribution data receiving unit opereible to 
ss externally receive the super distribution data; 

a super distribution data storage unit operable to 

store the super distribution data; 

a purchase processing unit operable to go through, 
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In response to a user's instruction, the purchase 
processing to reproduce the content included in the 
super distribution data stored in the super distribu- 
tion data storage unit; 

a data extracting unit operable to extract the super 
distribution data from the super distribution data 
storage unit; 

a content decrypting unit operable to decrypt, when 
the purchase processing Is carried out, the super 
distribution data stored in the super distribution 
data storage unit under the first system, and extract 
the content; 

a reproduction unit operable to reproduce the con- 
tent extracted by the content decrypting unit; and 
a distributor ID unit operable to encrypt a first user 
ID which is identification information unique to the 
apparatus, and add the encrypted first user ID to 
the super distribution data extracted by the data 
extracting unit for external output. 

[0010] As described above, in the second aspect, 
provided is a digital data recording and reproducing 
apparatus capable of charging a user appropriate royal- 
ties and accordingly protecting a copyright by distribut- 
ing super distribution data including content such as 
music. 

[0011] A third aspect of the present invention is 
directed to a billing processing unit operable to store 
super distribution data, and from a digital data recording 
and reproducing apparatus capable of reproducing a 
content after a billing processing, receive, over a net- 
work, billing control Information corresponding to the 
super distribution data, a distributor ID indicating who 
has distributed the super distribution data, and a trans- 
mitter ID corresponding to the digital data recording and 
reproducing apparatus, the billing processing unit com- 
prising: 

a billing processing Information receiving unit oper- 
able to receive the billing control infomiation and 
the distributor ID; 

a transmitter authorizing unit operable to receive 
the transmitter ID and Identify a transmitter; 
a billing processing unit operable to carry out, 
according to the billing control information received 
by the billing processing information receiving unit, 
the billing processing with respect to the transmitter 
identified by the transmitter authorizing unit; and 
a bonus processing unit operable to carry out a 
bonus processing for a distributor identified by the 
distributor ID received by the billing processing 
Information receiving unit. 

[0012] As described above, in the third aspect, pro- 
vided is a billing processing unit capable of protecting a 
copyright while charging a user appropriate royalties, 
and benefiting a copyright holder to a greater extent by 
offering a user identified by a distributor ID bonus to lure 



him/her to distribute the data. 

[0013] These and other objects, features, aspects 
and advantages of the present invention will become 
more apparent from the following detailed description of 
5 the present invention when taken in conjunction with the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 [0014] 

FIG. 1 is a block diagram showing the structure of a 
digital data copyright protection system according 
to a first embodiment of the present Invention; 
15 FIG. 2 is a schematic diagram showing the configu- 
ration of first super distribution data; 
FIG. 3 is a schematic diagram showing the contigu- 
ration of second super distribution data; 
FIG. 4 is a schematic diagram specifically showing 
20 how a user distributes, to other users, super distri- 
bution data which he/she had received under the 
present copyright protection system; 
FIG. 5 is a block diagram showing the structure of a 
digital data recording and reproducing apparatus of 
25 the first embodiment; 

FIG. 6 is a schematic diagram showing a first digital 
data recording and reproducing apparatus 1011 
implemented by a general computer; 
FIG. 7 is a flowchart showing the operation of the 
30 digital data recording and reproducing apparatus 
for acquiring right management information; 
FIG. 8 is a schematic diagrEun showing the struc- 
ture of a right management information managing 
table; 

35 FIG. 9 is a schemata diagram showing the struc- 
ture of super distribution data management infor- 
mation 1605; 

FIG. 10 is a flowchart showing the operation of the 
digital data recording and reproducing apparatus 
40 for reproduction; 

FIG. 11 is a block diagram showing the detailed 
structure of a distributor ID adding unit 41 1 ; 
FIG. 12 is a block diagram showing the detailed 
structure of a purchase processing unit 412; 
45 FIG. 13 is a schematic diagram showing an exam- 
ple of billing processing information; 
FIG. 14 is a flowchart showing the operation of the 
digital data recording and reproducing apparatus 
for purchase processing; 
50 FIG. 15 is a block diagram showing the detailed 
structure of a billing processing unit 801 ; 
FIG. 16 is a flowchart showing the operation of the 
billing processing unit 801 for the billing processing; 
FIG. 1 7 is a block diagram showing the structure of 
55 a digital data recording and reproducing apparatus 
according to a second embodiment; 
FIG. 18 is a diagram showing the structure of an 
SDAF package according to a third embodiment of 
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the present invention; 
FIGS. 19a to 19c are diagranns showing other struc- 
tures of the SDAF packages; 
FIG. 20 is a diagram showing how to split an SDAF 
title into SDAF paclcages; 5 
FIG. 21 is a diagram showing an example of the 
SDAF padcage; 

FIG. 22 is a diagram showing a header structure; 
FIGS. 23 and 24 show source codes describing the 
header structure using the C-m- language; io 
FIGS. 25a to 25c are diagrams showing how to 
define a CEL attribute table using a tag structure; 
FIG. 26 is a diagram showing a correspondence 
between key pairs and CEI^; 

FIG. 27 shows source codes describing the key pair is 
structure using the C++ language; 
FIG. 28 is a diagram showing how to refer to the 
CEL from navigation data; 

FIG. 29 is a diagram showing an example of the 

structure of the navigation data; 20 

FIG. 30 is a diagram showing an another example 

of the structure of the navigation data; 

FIG. 31 is a table showing specifications of 

MPEG2-AAG applied to an audio CEL; 

FIG. 32 is a table showing specifications of JPEG 25 

applied to an image CEL; 

FIG. 33 is a table showing specifications of MPEG- 
I frame applied to the image CEL; 
FIG. 34 is a table showing specifications of PNG 
applied to the image CEL; 30 
FIG. 35 is a table showing specifications of MPEG2 
applied to a video CEL; 

FIG. 36 is a diagram showing the structure of a time 
search map; 

FIGS. 37, 38a, and 38b are a table and diagrams 35 
showing a header included in the time search map 
in detail; 

FIG. 39 is a table showing each entry included in 
the time search map in detail; 

FIG. 40 is a table showing an example of CEL redi- 40 
rectors; 

FIGS. 41a to 41c are diagrams showing examples 

of how to distribute the SDAF package; 

FIGS. 42a to 42c are diagrams showing examples 

of how to create the SDAF package; 45 

FIG. 43 is an external view of a portable music 

player; 

FIG. 44 is a block diagram showing an example of 
the structure of the data conversion unit; and 
FIG. 45 is a block diagram showing another exam- so 
pie of the structure of the data conversion unit. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

55 

(First Embodiment) 

[0015] With reference to FIGS. 1, 2, and 3. 



described below is a digital data copyright protection 
system according to a first embodiment of the present 
invention. FIG. 1 is a diagram showing the structure of 
the digital data copyright protection system. 
[0016] The digital data copyright protection system 
includes first to third digital data recording and repro- 
ducing apparatuses 101 1 to 1013, a content server 102 
for distributing digital data, and a billing server 103 for 
going through a billing processing. These are intercon- 
nected via the Internet 104. l-lerein, the Internet is not 
restrictive, and may be a telephone line, dedicated net- 
work, satellite broadcast network, or CATV network. 
The number of digital data recording and reproducing 
apparatuses Is not an issue here. 
[0017] In FIG. 1 , the first to third digital data record- 
ing and reproducing apparatuses 1011 to 1013 are typ- 
ified by personal computers connected to the Internet. A 
user receives digital data through the Intemet or from 
media such as music CDs for reproduction on his/her 
digital recording and reproducing apparatus. 
[0018] FIGS. 2 and 3 are diagrams exemplarily 
showing the configuration of the digital data distributed 
through the intemet. The digital data in FIG. 2 includes 
right management information 203 and a content 205. 
The right management Information 203 includes billing 
control infomnation 201 and a content key 202. The con- 
tent 205 is composed of one or more pieces of audio 
data 204. l-lereinafter, such configured digital data is 
referred to as first super distribution data. 
[0019] The billing control information 201 includes 
Infomnation as to a bill for the content, availability for pre- 
viewing, the number of previewing, and the like. The bill- 
ing control information 201 may also include infomnation 
as to a billing arrangement which is based on the 
number of listenings, i.e., for every listening or a prede- 
termined number of listenings, and the number, for 
example. The content key 202 is used to encrypt and 
decrypt the content 205. The content 205 is previously 
encrypted by the content key 202. 
[0020] The right management information 203 is 
previously encrypted under a predetenmined encryption 
system with a key different from the content key 202. 
Such key is called a right management Information key 
(not shown), and is typically stored in software operable 
in the first to third digital data recording and reproducing 
apparatuses 101 1 to 1013. The software is installed by 
the user for use. Herein, the right management infomna- 
tion key may encrypt and decrypt the infomnation in 
hardware dedicated therefor. 

[0021] The right management infomnation key is 
stored in a region where no user is accessible with nor- 
mal operation. Such region inaccessible by the user is 
hereinafter refen-ed to as secured region. Here, the 
secured region is often provided in a built-in storage in a 
general computer device, but may be in dedicated hard- 
ware, storage, or storage medium. 
[0022] The digital data in FIG. 3 includes a user ID 
301 and first super distribution data 302 as shown In 
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FIG. 2. Such configured data is hereinafter refen^ed to 
as second super distribution data. 
[0023] The user ID 301 in FIG. 3 indicates informa- 
tion for identifying the user having the digital data dis- 
tributed to another. The user ID 301 is encrypted under 
a predetermined encryption system, and is uniquely 
provided to every user. The user ID 301 Is stored in the 
above-described secured region, and may be com- 
posed of several user specific IDs. The specific user ID 
is generated at Installation of such software as above in 
the copyright protection system, or provided from the 
billing server 103 or others over the networlc. Details 
about the possibility of the user ID 301 being composed 
of several specific user IDs are left for later description. 
[0024] A CD (external recording medium 417, 
which is later described) in this embodiment includes a 
content (music data) and content Identification Informa- 
tion for Identifying the content. The content identification 
infomnation is typified by a code called ISRG (Interna- 
tional Standard Recording Code) used to identify a 
music title. 

[0025] The content recorded on the CD is presuma- 
bly not encrypted. The CD herein may be an Enhanced- 
CD in which a region for music CD (CD-DA) and a CD- 
ROM region are combined. Further, the CD-ROM 
region therein may store the right management informa- 
tion 203 encrypted under a predetermined encryption 
system. 

[0026] Described below is digital data distribution 
under the present copyright protection system. Assum- 
ing that, with the first digital data recording and repro- 
ducing apparatus 1011, a user A purchases and 
reproduces some digital data (typically music), and 
he/she finds himself/herself liking the data and decides 
to suggest a user B to purchase the data. In such case, 
the user A may store the digital data in a storage 
medium and hand it to the user S, or directly transmits 
the data via the Internet This works well for both of 
them since the user v4 is not bothered to describe what 
the digital data is like (e.g., title of the music, name of 
the singer), and the user B merely receives the data 
from the user A, Afterward, the user B may also find 
himself/herself liking the music, and recommend it to 
another user C. If such wide-spreading digital data is 
billed for on the usage basis, copyright holders can 
enjoy benefits brought thereby. Basically, this copyright 
protection system is developed by taking such case into 
consideration. 

[0027] FIG. 4 is a diagram specifically showing the 
copyright protection system used for such case as 
above. In FIG. 4. with the first digital data recording and 
reproducing apparatus 1011, the user A presumably 
downloads music data from the content server 102 
(Step 1). and makes an online payment to the billing 
server 103 (Step 2). The user A then transmits the 
music data to the user 0 operating the second digital 
data recording and reproducing apparatus 1012 (Step 
3). The user B makes an online payment to the billing 



server 103 with respect to the music data (Step 4). 
Thereafter, the user 0 transmits the musk; data to the 
user C operating the third digital data recording and 
reproducing apparatus 1013 (Step 5). The user C 

5 makes an online payment to the billing server 103 with 
respect to the music data (Step 6). Herein, the users 
surely have an option not to pay for the music data, and 
may merely pass the music data to others. 
[0028] As such, the present copyright protection 

10 system can bill the users for the music data In the distri- 
bution process, benefiting the copyright holders to a 
greater extent. Moreover, the system may offer bonus 
such as coupon to encourage the users to distribute the 
music data thereamong. Details are left for later 

15 description. 

[0029] Next, the digital data recording and repro- 
ducing apparatus operated by the user as such is now 
described. FIG. 5 is a block diagram showing the struc- 
ture of the first digital data recording and reproducing 

20 apparatus 1011. The digital data recording and repro- 
ducing apparatus In FIG. 5 includes a super distribution 
data receiving unit 401 , a super distribution data storing 
region 402, an RMl acquiring unit 403. an RMI storing 
region 404, a content key extracting unit 405, a data 

25 reading unit 406, a data compressing unit 407, a data 
encrypting unit 408, an RMI adding unit 409, a data 
accessing unit 410, a distributor ID adding unit 411, a 
purchase processing unit 412, a content decrypting unit 
414, a reproduction controlling unit 415, a speaker 416, 

30 and a user ID storage region 41 8. 

[0030] Note herein that, the speaker 416 may be 
externally connected to the digital data recording and 
reproducing apparatus. Moreover, the RMI acquiring 
unit 403, the RMI storage region 404. the content key 

35 extracting unit 405, the data reading unit 406, the data 
compressing unit 407. the data encrypting unit 408, and 
the RMI adding unit 409 are provided, as will be 
described later, to convert unencrypted data, etc., to 
super distribution data. If there is no need for such con- 

40 version, these components may be omitted. Here, the 
second and third digital data recording and reproducing 
apparatuses 1012 and 1013 are structurally Identical to 
the first digital data recording and reproducing appara- 
tus 1011, and thus are not described again. 

45 [0031] Such digital data recording and reproducing 
apparatus is generally implemented by a personal com- 
puter. FIG. 6 is a schematic diagram showing the struc- 
ture of the first digital data recording and reproducing 
apparatus 1011 implemented by a general computer 

50 devtee. 

[0032] The apparatus in FIG. 6 includes an informa- 
tion processing unit 2 operable to carry out data 
processing and controlling other components, a pro- 
gram storage unit 3 operable to store program data 
55 required for operating the information processing unit 2, 
an output unit 4 operable to display various information 
for the user and reproducing and outputting music data, 
etc., an input unit 5 operable to receive the user's 
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instructions and data from an external storage medium, 
a general data storage unit 6 operable to store data 
such as super distribution data, a secure data storage 
unit 7 operable to store data which is to be kept secret 
from the user in a region inaccessible by normal opera- 
tion, and a communications unit 8 operable to communi- 
cate with various servers via the Internet. These 
components are connected via a common system bus. 
[0033] The input unit 5 is exemplarily composed of 
a CD-ROM reader, DVD reader, keyboard, and mouse, 
and receives the user's instructions, and data, data from 
an external recording medium such as CD-ROM, and 
the like. The output unit 4 is exemplarily composed of a 
display, printer, and speaker, and displays various infor- 
mation generated by the infonmation processing unit 2 
for the user, and plays back music. The information 
processing unit 2 exemplarily includes a CPU, and car- 
ries out various data processing to control other compo- 
nents while protecting a copyright of digital data. Such 
various data processing wilt be later described in detail. 
[0034] Herein, the information processing unit 2 
performs such various data processing with a program. 
The program is stored in the program storage unit 3. 
and is transmitted to the infomriation processing unit 2 
as required. The program storage unit 3 may be so con- 
figured as to store program information in a recording 
medium such as fixed storage including hard disk drive 
or semiconductor memory, or in an exchangeable 
recording medium such as optical disk (e.g., CD. DVD) 
and semiconductor memory card. If the recording 
medium In use is of an exchangeable type, it may be 
exchanged with another having a new program stored 
as appropriate. 

[0035] The general data storage unit 6 is composed 
of a storage which is readable and writable such as hard 
disk drive and semiconductor memory, and stores data 
which is not necessarily kept secret from the user such 
as the super distribution data. The secure data storage 
unit 7 may be a storage such as hard disk or dedicated 
hardware, or a storage having an encrypted storage 
region set therein, and stores data to be kept secret 
from the user in a region inaccessible by normal opera- 
tion. The communteations unit 8 is exemplarily com- 
posed of a modem and router, and communicates with 
the content server 102, billing server 103, or other dig- 
ital data recording and reproducing apparatuses via the 
Internet 

[0036] Note herein that, the digital data recording 
and reproducing apparatus is not limited to a peraonal 
computer, but may be implemented by the so-called 
STB (Set Top Box) which records broadcasting pro- 
grams. 

[0037] Next, the operation of the first digital data 
recording and reproducing apparatus 1011 shown in 
FIG. 5 is described. This apparatus operates differently 
between the super distribution data and the unen- 
crypted data. Described next below is a first case where 
the user A receives the super distribution data, i.e., the 



first super distribution data in FIG. 2 or the second super 
distribution data in FIG. 3. 

[0038] In FIG. 5, the first or second super distribu- 
tion data Is provided to the super distribution data 

5 receiving unit 401 from the content server 1 02, the sec- 
ond or third digital recording and reproducing apparatus 
1012 or 1013 operated by other user, or the external 
recording medium 417 such as CD. The data is then 
stored in the super distribution data storage region 402. 

10 The storage location of the data is written to super dis- 
tribution data management information, which will be 
described later in detail, stored in the secured region. 
Although the secured region may be separately pro- 
vided from other storage regions. It is provided in the 

15 super distribution data storage region 402 in this appa- 
ratus. 

[0039] Described next is a second case where the 
user A receives the unencrypted music data from the 
external recording medium 417 such as CD. The unen- 

20 crypted music data may come from the content server 
1 02 or others. If that is the case, however, copyright pro- 
tection thereof is hardly protected, and thus such data is 
not taken Into consideration here. Further, if the digital 
data recording and reproducing apparatus is configured 

25 without the RMI acquiring unit, the RMI storage region 
404, the content key extracting unit 405, the data read- 
ing unit 406, the data compressing unit 407, the data 
encrypting unit 408, and the RMI adding unit 409. the 
following operation Is not carried out. 

30 [0040] In FIG. 5, the data reading unit 406 reads, 
from the external recording medium 417, unencrypted 
music data corresponding to the content 205 including 
the audio data 204. The RMI acquiring unit 403 
acquires right management information from the con- 

35 tent server 1 02 or the external recording medium 41 7. 
The acquired right management information is stored in 
the RMI storage region 404. 

[0041] FIG. 7 is a flowchart showing the detailed 
operation of the first digital data recording and repro- 

40 ducing apparatus 1011 for acquiring the right manage- 
ment information. In step S901, the RMI acquiring unit 
403 acquires content identifying information from the 
external recording medium 41 7 such as CD. The con- 
tent identifying information is an identification code such 

45 as ISRC or title information provided to identify the con- 
tents. 

[0042] In step S902. the RMI acquiring unit 403 
determines whether or not the external recording 
medium 417 has right management information corre- 

50 spending to the content specified by the acquired con- 
tent identifying Information. If yes. the procedure goes 
to step S903, and otherwise, goes to step S904. 
[0043] In step S903, the RMI acquiring unit 403 
acquires the right management information from the 

55 external recording medium 417. The procedure then 
goes to step S905. Note herein that, the right manage- 
ment information recorded on the extemat recording 
medium 417 Is encrypted under a predetermined 
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encryption system. Herein, the right managennent infor- 
mation may be recorded on the extemat recording 
medium such as CD or in a secured region of other type 
of recording medium such as SD (Secure Digital) card. 
[0044] In step S904, the RMI acquiring unit 403 
communicates with the content server 1 02 with security, 
and acquires right management information. Then, the 
procedure goes to step S905. 

[0045] In step S905, the acquired right manage- 
ment infomnation is stored in the RMI storage region 
404, specifically, in a predetermined secured region 
provided in the digital data recording and reproducing 
apparatus 1011. Alternatively, the right management 
information is encrypted under a predetermined encryp- 
tion system, and a decryption key therefor is only stored 
in the secured region. 

[0046] In step S906, the RMI acquiring unit 403 
adds information relevant to the newly acquired right 
management information to a right management infor- 
mation managing table, which is for managing the right 
management infomnatlon in the RMI storage region 404. 
[0047] FIG. 8 is a diagram showing an exemplary 
structure of the right management information manag- 
ing table. In FIG. 8, the right management infomriation 
managing table Includes an Index number 1501 , content 
identifying infomnatlon 1502, and right management 
information storage location information 1503. The 
index number 1501 is assigned, in ascending order, to 
every right management infomriation in the RMI storage 
region 404. In the example in FIG. 8, the RMI storage 
region 404 has seven different right management infor- 
mation. 

[0048] The content identifying infomnatlon 1502 
includes the above-described content identifying infor- 
mation uniquely for each right management information. 
The right management infomnation storage location 
information 1503 indicates the location where the right 
management infomnation is stored. In the example in 
FIG. 8, the seven different right management infomna- 
tion is each stored in a file in a Header directory in C- 
drive. 

[0049] The content read from the data reading unit 
406 is compressed by the data compressing unit 407 in 
a predetermined manner. Although the content is not 
necessarily compressed, the smaller data size is prefer- 
able for transmission/reception through the Internet. In 
terms of region size for storage, it is also preferable. 
[0050] The compressed content is encrypted by the 
data encrypting unit 408. A key used to encrypt the con- 
tent is the one extracted by the content key extracting 
unit 405 from the right management information stored 
in the RMI storage region 404. 

[0051] The RMI adding unit 409 adds the right man- 
agement information to the data encrypted by the data 
encrypting unit 408 so as to generate the first super dis- 
tribution data. Such generated first super distribution 
data is stored in the super distribution data storage 
region 402, and the storage location thereof is written to 



the super distribution data management Information 
stored in the secured region. 

[0052] FIG. 9 Is a diagram showing an exemplary 
structure of super distribution data management infor- 

5 mation 1 605. The super distribution data management 
information 1605 in FIG. 9 includes an index number 
1601, data storage location information 1602, and a 
state of purchase 1603. The index number 1601 is 
assigned, in ascending order, to every super distribution 

10 data stored in the super distribution data storage region 
402. The data storage location Information 1602 indi- 
cates the location where the super distribution data is 
stored. In the example in FIG. 9, the super distribution 
data is stored in seven different folders. The state of pur- 
rs chase 1603 indicates whether the super distribution 
data has been already purchased or not. 
[0053] If the super distribution data reached the 
super distribution data storage region 402 is the one 
came from the super distribution data receiving unit 

20 401 , the state of purchase 1 603 corresponding to the 
data is "not-yet-purchased". After a later-described bill- 
ing processing completed, the state of purchase 1603 is 
changed to "purchased". Herein, the state of purchase 
1 603 may be indicated by a predetemnined figure or a 

25 flag corresponding to a predetemnined bit 

[0054] If the super distribution data reached the 
super distribution data storage region 402 Is the one 
obtained by encrypting data read by the data reading 
unit 406 from the external recording medium 41 7, for 

30 example, and by converting the data into the super dis- 
tribution data by the RMI adding unit 409. the state of 
purchase 1603 corresponding to the data is "pur- 
chased". This is because the user has already pur- 
chased the external recording medium 417. 

35 [0055] Described next is the operation of the digital 
data recording and reproducing apparatus 101 1 in FIG. 
5 for reproducing such stored super distribution data 
therein and distributing the data to other users. 
[0056] Referring to FIG. 5, in response to the user's 

40 Instruction for reproducing a certain content, an extrac- 
tion instructing unit (not shown) instructs the data 
accessing unit 41 0 to read the appricable super distribu- 
tion data from the super distribution data storage region 
402. The data accessing unit 410 then follows the 

45 instruction. 

[0057] In the case that the billing processing has 
been already completed or previewing is available, the 
content decrypting unit 41 4 takes out the content 205 
shown in FIG. 2 from the super distribution data 

so accessed and extracted by the data accessing unit 41 0. 
The reproduction controlling unit 415 controls reproduc- 
tion of the extracted content, and then instructs the 
speaker 416 to output audio data. 
[0058] Such content decrypting unit 414 and the 

55 reproduction control unit 415 are described in detail for 
their operations by refening to FIG. 1 0. FIG. 1 0 Is a flow- 
chart showing the processing carried out to reproduce 
the super distribution data stored in the super distribu- 
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tion data storage region 402. 

[0059] In step S1301, the content decrypting unit 
414 takes out, from the super distribution data extracted 
by the data accessing unit 41 0, the content Icey 202 and 
the billing control infornnation 201 included in such right 
management information 203 as shown in FIG. 2. As 
already described, a specific software uses the right 
management information icey to decrypt such informa- 
tion. 

[0060] In step SI 303, the content decrypting unit 
414 refers to the super distribution data management 
information 1 605 and checl<s whether the state of pur- 
chase 1 603 for the super distribution data to be repro- 
duced indicates "purchased". If yes, the procedure 
jumps to step SI 305, and otherwise, goes to step 
S1304. 

[0061] In step 81 304, the content decrypting unit 
414 refers to the billing control infonnatlon 201 included 
in the decrypted right management information 203, 
and checks whether previewing is available. If available, 
the procedure goes to step 81305, and otherwise, this 
is the end of the processing and the decrypted content 
is discarded. If the previewing is available for several 
number of times, the number is referred to In the billing 
control infornnation 201. The previewing is available for 
the number of times, which is decremented by every lis- 
tening. 

[0062] In step S1305, the content decrypting unit 
414 uses the extracted content key 202 to decrypt the 
encrypted content included in the super distribution 
data accessed and extracted by the data accessing unit 
410. Further, the reproduction controlling unit 415 con- 
trols reproduction of the extracted content, and then 
instructs the speaker 416 to output music, for example. 
Herein, in order to record the number of listenings for 
the content, the number of listenings in the right man- 
agement information 203 is incremented, and then the 
information is encrypted again and converted back into 
the super distribution data for storage In the super distri- 
bution data storage region 402. Similarly, when the 
number of permissive previewing is already set, the 
number in the right management information 203 is dec- 
remented, and then the information Is encrypted again 
and converted back into the super distribution data for 
storage. Further, if the billing is made for every listening, 
the corresponding state of purchase 1603 is changed to 
"not-yet-purchased" immediately after the playback. 
[0063] Described below is a case where the content 
is distributed to other users. Referring to FIG. 5, In 
response to the user's Instruction for distributing some 
super distribution data, similarly to the case for repro- 
duction, the extraction instructing unit instructs the data 
accessing unit 41 0 to access and extract the applicable 
super distribution data. The distributor ID adding unit 
411 searches the user ID storage region 418 for the 
specific user ID so as to generate the second super dis- 
tribution data 505 therewith. The generated second 
super distribution data 505 is exemplarity transmitted to 



the second digital data recording and reproducing appa- 
ratus 1012. Herein, the data can surely be transmitted 
to other digital data recording and reproducing appara- 
tuses, or recorded in an easy-to-cany recording 

5 medium such as SD card and handed to other users. 
[0064] Next below, the distributor ID adding unit 41 1 
is described for its structure and operation in detail. FIG. 
1 1 Is a block diagram showing the detailed structure of 
the distributor ID adding unit 411. The distributor ID 

10 adding unit 41 1 In FIG. 1 1 includes a user ID acquiring 
unit 501 , a user ID encrypting unit 502, a user ID adding 
unit 503, and a management infornnation acquiring unit 
504. 

[0065] The user ID acquiring unit 501 acquires a 
15 specific user ID from the secured region, i.e., the user 
ID storage region 418. The specific user ID is an identi- 
fication code uniquely provided to each user or digital 
data recording and reproducing apparatus. Note herein 
that, the specific user ID may be previously stored in the 
20 user ID storage region 41 8, or may be provided by an ID 
providing server or the billing server 103 through a pre- 
determined procedure. 

[0066] The management information acquiring unit 
504 reads, via the data accessing unit 410, the super 
25 distribution data management information 1605 stored 
in the secured region. Thereafter, the state of purchase 
1 603 in the read super distribution data management 
Information 1605 is inputted to the user ID encrypting 
unit 502. 

30 [0067] The user ID encrypting unit 502 then writes 
the state of purchase 1603 inputted from the manage- 
ment infomnation acquiring unit 504 to the user ID 
acquired by the user ID acquiring unit 501 . Typically, the 
user ID is composed of ID and the state of purchase. 

35 Thereafter, the user ID encrypting unit 502 encrypts the 
user ID under a predetermined encryption system. 
[0068] The user ID adding unit 503 adds the user ID 
encrypted by the user ID encrypting unit 502 to the 
super distribution data accessed and extracted by the 

40 data accessing unit 41 0, and thus generates the second 
super distribution data 505. 

[0069] In the case that the super distribution data 
accessed and extracted by the data accessing unit 41 0 
is the first super distribution data having no user ID 301 

45 provided, simply the distributor ID may be provided 
thereto. On the other hand, for the second super distri- 
bution data having the user ID already provided, the dis- 
tributor ID may be added in various manners. 
[0070] For example, the already-provided user ID 

50 may be deleted before the distributor ID is added, or 
accompanied by the distributor IDs in time order. For the 
latter case that the distributor IDs are plural, the number 
thereof may be limited to the last several. Herein, the 
user IDs are assumed to be the last two, specifically, the 

55 distributor ID of this apparatus is followed by another 
distributor ID belonging to the apparatus from which the 
data has been distributed. 

[0071] In such manner, no matter which type of 
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super distribution data is accessed and extracted by the 
data accessing unit 410, i.e., the first or second super 
distribution data, the user ID adding unit 503 adds the 
encrypted user ID at the head thereof so that the user 
IDs are the last two at most The second super distribu- 
tion data 505 is thus generated. 
[0072] Described next below is the purchase 
processing in the digital data recording and reproducing 
apparatus 1011. As described in the foregoing, the 
super distribution data stored in the super distribution 
data storage region 402 includes the data not-yet-pur- 
chased. Therefore, In response to the user's instruction 
for purchase, a purchase instructing unit (not shown) 
instructs the purchase processing unft 412 to read the 
super distribution data storage region 402 for the appli- 
cable super distribution data. The purchase processing 
unit 412 then follows the instruction, and then goes 
through the billing processing. 

[0073] FIG. 12 is a block diagram showing the 
detailed structure of the purchase processing unit 412. 
The purchase processing unit 412 in FIG. 12 includes 
an RMI extracting unit 601, a billing control infomnation 
extracting unit 602, a distributor ID extracting unit 603, a 
billing processing infonnation generating unit 604, a bill- 
ing processing information transmitting unit 605, a 
transmitter ID transmitting unit 606, a normal termina- 
tion receiving unit 607, and a super distribution data 
management information rewriting unit 608. 
[0074] The RMI extracting unit 601 extracts right 
management information from the read super distribu- 
tion data 610. The billing control infomnation extracting 
unit 602 then extracts billing control information from the 
right management infomnation extracted by the RMI 
extracting unit 601. If the read super distribution data 
has any user ID added, the distributor ID extracting unit 
603 extracts the user ID, and then instructs the billing 
processing infomnation generating unit 604 to add the 
extracted user ID. To the extracted billing control infor- 
mation, the billing processing information generating 
unit 604 adds the user ID extracted by the distributor ID 
extracting unit 603 so as to generate the billing process- 
ing information 611. As such, the billing processing 
information transmitting unit 605 transmits such gener- 
ated billing processing information 611 to the billing 
server 103. 

[0075] FIG. 13 is a diagram showing an exemplary 
structure of the billing processing information 61 1. The 
billing processing information 611 in FIG. 13 includes 
billing control information 702 extracted by the billing 
control information extracting unit 602, and a user ID 
701 extracted by the distributor ID extracting unit 603. 
Herein, when the read super distribution data has no 
user ID added, the billing processing information 61 1 
includes only the billing control information 702. The 
user ID 701 extracted by the distributor ID extracting unrt 
603 may include not only the distributor ID belonging to 
the user who has distributed the data to the apparatus 
but another involved in data distribution precedent 



thereto. 

[0076] Simultaneously or immediately after the bill- 
ing processing information transmitting unit 605 trans- 
mits such billing processing infomnation 61 1 as in FIG. 

5 13, the transmitter ID transmitting unit 606 transmits, to 
the billing server 103, a transmitter ID 612, which is the 
specific user ID acquired from the secured region for the 
purpose of identifying the transmitter. Typically, such 
information is sequentially transmitted as a set of data. 

10 [0077] The normal termination receiving unit 607 
receives, from the billing server 103, a billing processing 
normally terminated notice 613, which tells that the bill- 
ing processing has been normally completed. Once the 
billing processing normally terminated notice 613 is 

15 received, the super distribution data management infor- 
mation rewriting unit 608 changes the state of purchase 
1603, from "not-yet-purchased" to "purchased", in the 
super distribution data management information 1605 
stored in the super distribution data storage region 402. 

20 [0078] Described next is the operation for purchas- 
ing such super distribution data by referring to a flow- 
chart shown in FIG. 14. In step S1201 in FIG. 14, the 
RMI extracting unit 601 extracts right management 
infomnation from the read super distribution data 610. 

25 [0079] In step SI 202, the billing control information 
extracting unit 602 uses the above-described right man- 
agement information key to decrypt the extracted right 
management infonnation. Such decryption is can-led 
out by a dedicated software as described in the forego- 

30 ing. In step 81 203, the billing control information 
extracting unit 602 extracts billing control information 
from the decrypted right management information. The 
extracted billing control infonnation is the one included 
in the billing processing information 61 1 . 

35 [0080] In step SI 204, the distributor ID extracting 
unit 603 determines whether the read super distribution 
data is the second super distribution data. If yes, the 
procedure goes to step S1205, and otherwise, jumps to 
step SI 207. 

40 [0081] In step S1205, the distributor ID extracting 
unit 603 extracts the user ID from the second super dis- 
tribution data. In step SI 206, the distributor ID extract- 
ing unit 603 then adds the extracted user ID to the billing 
control information so as to generate such billing 
45 processing information 61 1 as shown in FIG. 13. 

[0082] In step S1207, the billing processing infor- 
mation transmitting unit 605 transmits the billing 
processing information 611 to the billing server 103. 
Simultaneously therewith, or sequentially, the transmit- 
so ter ID transmitting unit 606 acquires the transmitter ID 
from the secured region, and then transmits the trans- 
mitter ID to the billing server 103. 
[0083] In step SI 208, after a lapse of time taken for 
the billing server 103 to go through the processing, the 
55 normal termination receiving unit 607 determines 
whether the billing processing normally terminated 
notice 613 has been transmitted from the billing server 
103. If yes, the procedure goes to step SI 209, and oth- 
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envise, returns to step SI 207. Herein, tf the billing 
processing normally terminated notice 613 is not trans- 
mitted no matter how many times the processing in step 
SI 207 is repeated, the billing server 103 may have 
gone down. Accordingty. a predetermined processing 5 
(not shown) is carried out to handle errors. 
[0084] In step S1209, the super distribution data 
management information rewriting unit 608 reads the 
super distribution data management information 1 605 
from the super distribution data storage region 402, 10 
changes the state of purchase 1603 therein from "not- 
yet-purchased" to "purchased*, and then records the 
information again in the super distribution data storage 
region 402. 

[0085] In the above description, the billing process- is 
ing information is presumed to be transmitted to the bill- 
ing server online. However, the billing processing 
information may be once stored In the digital data 
recording and reproducing apparatus, and then trans- 
mitted to the billing server whenever is appropriate. 20 
[0086] Next, the billing server 103 carrying out the 
billing processing is described for its structure and oper- 
ation. FIG. 15 is a diagram showing the structure of a 
billing processing unit 801 provided In the billing server 
103. The billing processing unit 801 In FIG. 15 includes 25 
a billing processing information receiving unit 802, a 
transmitter authorizing unit 803, a billing processing unit 
804, a normal termination notifying unit 805, a distribu- 
tor ID extraaing unit 806, a distributor ID decrypting unit 
807, and a bonus processing unit 808. 30 
[0087] The billing processing information receiving 
unit 802 receives the billing processing information 61 1 
transmitted from the purchase processing unit 412. The 
billing processing information then goes to the billing 
processing unit 804 and the distributor ID extracting unit 35 
806. The transmitter authorizing unit 803 receives the 
user ID 612 came from the purchase processing unit 
412 in the first digital data recording and reproducing 
apparatus 101 1, and then specifies the transmitter. 
[0088] Based on the billing control information 40 
included in the received billing processing information, 
the billing processing unit 804 carries out the billing 
processing with respect to the user specified by the 
transmitter authorizing unit 803. The normal termination 
noticing unit 805 then transmits the billing processing 45 
nomnalty terminated notice 613 to the purchase 
processing unit 412 in the first digital data recording and 
reproducing apparatus 1011. 

[0089] ff the billing processing information 611 is 
provided with the user ID specifying the distributor, the so 
distributor ID extracting unit 806 extracts the distributor 
ID. As described In the foregoing, the extracted distribu- 
tor ID may be both the current and previous distributor 
IDs. The distributor ID decrypting unit 807 decrypts the 
distributor ID extracted by the distributor ID extracting 55 
unit 806. The bonus processing unit 808 goes through 
the bonus processing with respect to the user specified 
by the decrypted user ID. Details are described later. 



[0090] Described next Is the detailed operation of 
the billing processing unit 801 by referring to FIG. 16. 
FIG. 16 is a flowchart showing the processing for each 
component in the billing processing unit 801 . 
[0091] In step S1401. the billing processing infor- 
mation receiving unit 802 receives the billing processing 
infomnation 61 1 from the purchase processing unit 412, 
while the transmitter authorizing unit 803 receives the 
transmitter ID from the purchase processing unit 412. 
[0092] In step SI 402, the billing processing unit 804 
carries out the billing processing with respect to the 
user specified by the transmitter ID received by the 
transmitter authorizing unit 803. This processing is done 
based on the billing control infonmatlon included In the 
billing processing information which has been received 
by the billing processing information receiving unit 802. 
Herein, as already described, the billing control informa- 
tion includes a bill, for example, necessary for billing. 
[0093] In step S1403, the distributor ID extracting 
unit 606 determines whether the billing processing infor- 
mation received by the billing processing information 
receiving unit 802 is provided with any user ID. If yes, 
the procedure goes to step S1404, and otherwise. 
Jumps to step SI 406. 

[0094] In Step S1404, the distributor ID decrypting 
unit 807 decrypts the user ID in a predetermined man- 
ner. Herein, the user ID may be both the current and 
previous distributor IDs. 

[0095] In step S1405, the bonus processing unit 
808 carries out the bonus processing with respect to the 
user specified by the decrypted user ID. The user, 
thereby. Is offered with discount or coupon, which is 
effective for the next bill. Herein, as described in the 
foregoing, the user entitled to such bonus may be both 
the current and previous distributors. If this is the case, 
the bonus processing unit 808 increases the discount 
rate or the face value of coupon for the cun-ent distribu- 
tor more than the previous distributor. This is because, 
the current distributor is the one who directly involved 
with the data distribution, but the previous distributor 
indirectly. 

[0096] The decrypted user ID is provided with the 
above-described billing infonmation. Accordingly, for the 
user who has already purchased the music data, the 
bonus processing unit 808 increases the discount rate 
or the face value of coupon more than the user who has 
not yet. 

[0097] As is Icnown from the above, in the present 
digital data copyright protection system, user's bill pay- 
ment and his/her contribution to the distribution deter- 
mine the discount rate or the face value of coupon. In 
this manner, the user may be willing to purchase data or 
involve In the data distribution to increase the value of 
his/her bonus. With such user's involvement, the 
present digital data copyright prctection system can 
benefit copyright holders to a greater extent while pro- 
tecting their copyrights. 

[0098] In the above, the bonus for the user is exem* 
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ptarity discount or coupon, but Is not restrictive thereto. 
The bonus may be varied to a point exchangeable with 
merchandise, merchandise, or special service, anything 
is possible as long as the bonus attracts the users well 
enough. 

(Second Embodiment) 

[0099] A digital data copyright protection system 
according to a second embodiment of the present 
invention is almost the same as the one described in the 
first embodiment. Spectficalty, the content server 102 
and the billing server 103 herein are identical to those in 
the first embodiment. In addition, the digital data record- 
ing and reproducing apparatus herein is also almost the 
same in structure. Therefore, in the second embodi- 
ment, only any difference from the first embodiment is 
described. Any identical component shares the same 
reference numeral, and is not described again. 
[0100] FIG. 17 is a block diagram showing the 
structure of a digital data recording and reproducing 
apparatus 1701 of the second embodiment. In FIG. 17, 
the digital data recording and reproducing apparatus 
1701 includes the super distribution data receiving unit 
401 , the super distribution data storage region 402, the 
RMI^acquiring unit 403, the RMI storage region 404, the 
content key extracting unit 405, the data reading unit 
406, data compressing unit 407, the data encrypting 
unit 408, the RMI adding unit 409, the data accessing 
unit 41 0, the distributor ID adding unit 41 1 , the purchase 
processing unit 412. the content decrypting unit 414, 
the reproduction control unit 415, the speaker 416, the 
user ID storage region 418, a data adding unit 1702, an 
additional information storage region 1703, and a dis- 
play 1 704. 

[0101] As is known from the above, the difference 
from the first digital data recording and reproducing 
apparatus 1011 of the first embodiment is in that the 
data adding unit 1702, the additional information stor- 
age region 1703, and the display 1704 are additionally 
provided. Described next below is the operation of the 
data adding unit 1702. 

[0102] The data adding unit 1702 reads, from the 
additional information storage region 1 703, image data 
previously provided by the user and/or additional infor- 
mation including reproduction control infomriatlon as to 
the image data and audio data. Such Image data and/or 
information is added to the audio data which has been 
compressed by the data compressing unit 407. Typi- 
cally, the additional Information is provided at the tail of 
the audio data, which is composed of one or more 
pieces. Specifically, the additional information Is pro- 
vided at the tail of the audio data 204 in the content 205 
in FIG. 2. Note herein that, the additional infonmation 
may be previously provided to the audio data to be com- 
pressed together with the audio data. 
[0103] Herein, the image data provided by the user 
is displayed at a predetermined timing when the content 



Is reproduced. The reproduction control information is 
for to control reproduction of the content. For example, 
the reproduction control information controls an order 
and timing to reproduce the audio data, if plural, or con- 
5 trols a timing to display the image data provided by the 
user. 

[0104] The data encrypting unit 408 subjects the 
audio data having the image data added by the data 
adding unit 1702 to encryption. Surety, only the audio 

10 data may be encrypted. Now and onwards, the digital 
data recording and reproducing apparatus 1701 oper- 
ates in a simitar manner to the first digital data recording 
and reproducing apparatus 1011 of the first embodi- 
ment, and is not descrilaed again. 

15 [0105] Note herein that, in the apparatus shown in 
FIG. 1 7, the speaker 41 6 is used to reproduce the con- 
tent, and the display 1704 may be also used to display 
the Image. As already described by referring to FIG. 6, 
when this apparatus is implemented by a common per- 

20 sonal computer, the display may be a CPCV or others to 
display various information. Therefore, when the con- 
tent includes the image data, the image is to be dis- 
played on the display 1704 popular for the personal 
computer. 

25 [0106] As described in the foregoing, according to 
the present digital data copyright protection system, 
there is no more need to encrypt CDs to charge appro- 
priate royalties therefor and protect the copyright 
thereof. Further, with the reproduction control informa- 

30 tion on image and audio provided by the user, the music 
content for distribution as super distribution data can be 
more entertaining. 

(Third Embodiment) 

35 

[0107] As the third embodiment, as a specific 
example of super distribution data as mentioned in the 
first and second embodiments, a content distribution 
format called SDAF (Secure Digital Audio Format) Is 

40 described below. Referring to FIGS. 1 8 to 39. details on 
the SDAF is first described, and then referring to FIGS. 
40 to 45, how to use the SDAF Is described. 
[0108] The content distribution fonmat (SDAF) 
according to the present embodiment is used for 

45 describing multimedia contents that include audio. 
Images, video, text, and file data. The multimedia con- 
tents described with SDAF are herein called an SDAF 
title. Presentation data each comprising the SDAF title 
is herein called a content element (hereinafter abbrevi- 

50 ated as GEL). Each CEL is assigned a CEL Identifier 
that is unique in the SDAF title (hereinafter abbreviated 
as CEL_ID). 

[0109] The SDAF title is distributed as being split 
into units called SDAF packages. Each SDAF package 
55 is assigned a package identifier that is unique in the 
entire distribution system. FIG. 1 6 is a diagram showing 
an example of the SDAF package. As shown in FIG. 18, 
an SDAF title 2000 is composed of a plurality of SDAF 
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packages. Each package 2001 is composed of a header 
2011, navigation data 2012, a plurality of CELs 2013, 
and an offer 201 4. 

[0110] The header 2011 includes information such 
as location, size, and attribute of each data In the pack- s 
age. Such information defines the package structure. 
The navigation data 2012 is playback control informa- 
tion specifying the operation of the player in playing 
back the SDAF title. From the navigation data 2012, a 
CEL included in the package to which the navigation w 
data belong or in other packages is referred to. The CEL 
2013 is obtained by encrypting each presentation data 
composing the SDAF title, and more specifically, by 
encrypting audio, images, video, text, or file data. A pair 
of a decryption key for decrypting the CEL 2013 and is 
CELJD is called a key pair. The offer 2014 includes a 
plurality of key pairs, and purchase rules describing the 
purchase price and available period for each key pair. 
[0111] FIGS. 19a to 19c are diagrams showing 
three types of SDAF packages. A full package 2001 20 
shown in FIG. 19c includes, similarly to FIG. 18, a 
header 2011, navigation data 2012. a plurality of CELs 
2013, and an offer 2014. An offer package 2002 shown 
in FIG. 19a includes the header 2011, the navigation 
data 201 2, and the offer 201 4, but does not include any 25 
CEL 2013. A CEL package 2003 shown in FIG. 19b 
includes the header 2011 and the plurality of CELs 
2013. Since the navigation data 2012 Is required for 
playing back the SDAF title, the full package 2001 and 
the offer package 2002 can be played back alone, but 30 
the CEL package 2003 cannot 

[0112] The CEL package is used for splitting the 
SDAF title according to the distribution channel. For 
example, when distributed by using a CD-ROM, the 
SDAF title is recorded as a full package in the CD-ROM. 35 
On the other hand, when distributed through the Inter- 
net, the SDAF title Is split into one full package and a 
plurality of CEL packages for distribution. For example, 
the SDAF title is split into one full package including an 
audio CEL and a plurality of CEL packages including a 40 
video CEL that is referred to from the full package for 
distribution. 

[0113] Further, as shown In FIG. 20, the SDAF title 
may be split into a plurality of SDAF packages by tracks. 
In package division as shown in FIG. 20, an SDAF title 45 
2020 including audio data for five tracks is split Into 
three packages 2021 to 2023. The first to third pack- 
ages 2021 to 2023 have package names Singlel, 
Single2, and album, respectively. The first and second 
packages 2021 and 2022 both include an audio CEL for so 
one track and navigation data for controlling playback of 
the CEL. The third package 2023 includes an audio 
CEL for three tracks and navigation data for controlling 
playback of all audio CELs included in the first to third 
packages 2021 to 2023. As such, by dividing the SDAF ss 
title into a plurality of SDAF packages, it is possible to 
make each data size smaller and easily handle each 
data. 



[01 1 4] The header, offer, navigation data, and CEL, 
which compose the SDAF package, are described in 
this order below. 

[0115] The header 201 1 is first described, l-lere, an 
SDAF package shown in FIG. 21 is taken as an exam- 
ple, and a header 2031 of an SDAF package 2030 is 
described. In the SDAF package 2030, it is herein 
assumed that the size of navigation data 2032 and the 
size of an offer 2034 are 400H each, in hexadecimal 
notation. This package includes three CELs 2033, and 
the types thereof are, from first, audio, image, and file. It 
is assumed here in that the sizes of these CELs are, 
from first. 400000H, 18000H. and 8000H in hexadeci- 
mal notation. 

[0116] FIG. 22 is a diagram showing the structure of 
the header 2031 . In the header 2031 , data as described 
below is sequentially stored, and the size of the header 
Is BCH in hexadecimal notation. Note that the structure 
of the header 2031 can be described in the C++ lan- 
guage as shown in FIGS. 23 and 24. FIGS. 23 and 24 
are a diagram showing a sequential source code as 
being split into two, and before division, a source code 
2082 shown in FIG. 24 follows a source code 2061 
shown in FIG. 23. 

[0117] At the start of the header 2031, a magic 
number 2041 (4 bytes) indicating that the file is in the 
SDAF format is stored. The value of the magic number 
2041 is a character string "SDAF", Then, a version 
number 2042 (4 bytes) of the SDAF is stored. Then, a 
package ID 2043 (1 6 bytes) and a package size 2044 (4 
bytes) are stored. Then, navigation data location infor- 
mation 2045 (SDAF_LOCATION_NAV in FIG. 23), offer 
location information 2046 (SDAF_LOCATION_OFFER 
in FIG. 23), and the number of CELs in the package 
2047 are stored. Then, CEL infonnation 2048 
(SDAF_LOCATION_CEL In FIG. 24) for each CEL is 
stored. Lastly, a CEL attribute table 2049 indicating an 
attribute of each CEL is stored. 

[0118] The navigation data location infonnation 
2045 indicates the location and size of the navigation 
data 2032. The offer location information 2046 indicates 
the location and size of the offer 2034. These two pieces 
of information are both composed of an offset (4 bytes) 
from the start of the SDAF package and each size (4 
bytes) thereof. 

[0119] The CEL information 2048 is composed of a 
CELJD 2051 (16 bytes), a CEL type 2052 (2 bytes), a 
CEL encryption type 2053 (2 bytes), a CEL data loca- 
tion infonnation 2054, and a CEL attribute table location 
infomiation 2055. The CELJD 2051 is a content ele- 
ment identifier that is unique in the SDAF title. The CEL 
type 2052 takes any value of audio, image, video, text, 
and file. The CEL encryption type 2053 indicates an 
algorithm used for encrypting the CEL. The CEL data 
location information 2054 and CEL attribute table loca- 
tion information 2055 are both composed of an offset (4 
bytes) from the start of the SDAF package and each 
size (4 bytes) thereof, if the offset or size is 0, that 
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means no data exists. 

[0120] The CEL attribute table 2049 is a list of 
attributes specified for each CEL type. An audio CEL 
attribute table (SADF_ATTR_AUDIO in FIG. 24) 
includes at least CODEC, the number of quantized bits, 
sampling frequency, and the number of audio channels. 
An image CEL attribute table (SDAF_ATTR_GRAPHIC 
in FIG. 24) Includes at least the height and width of the 
image and the encryption type. A video CEL attribute 
table includes at least the height and width of the video 
and the encryption type. A text attribute table Includes at 
least the encryption type of the text, such as Unicode or 
music shift JIS (Japanese Industrial Standards). A file 
CEL attribute table includes at least the type of MIME 
(Multipurpose Intemet Message Extension). 
[0121] The CEL attribute table 2049 is defined not 
as a fixed-length table but with a variable-length tag 
structure as shown in FIGS. 25a to 25c. If the tag struc- 
ture is used, a tag length and tag ID are stored preced- 
ing the data, as shown in FIG. 25a. For example, the 
image CEL attribute table is composed of a characteris- 
tic tag 2063 and an encryption type tag 2064. The table 
elements are specified by using the tag structure, 
thereby a new table element can be added to the data 
format or the data format can be changed only by add- 
ing a tag. The CEL attribute table is specified by using 
the tag structure with a great potential for expansion. 
[0122] Next, the offer 2014 is described. As stated 
above, the offer includes a plurality of key pairs and pur- 
chase rules for each key pair. Each key pair is com- 
posed of a decryption key for decrypting the CEL and a 
CEL„ID. FIG. 26 is a diagram showing the correspond- 
ence between the key pair and the CEL. As shown in 
FIG. 26, a key pair 2072 is composed of a decryption 
key 2073 and a CEL_ID 2074, and each key pair 2072 
is related to each CEL 2071. The offer includes not only 
the key pair of the CEL included in the SDAF package 
but also all key pairs of the CELs included In the SDAF 
packages of the same SDAF title. In other words, when 
one SDAF title is split into a plurality of SDAF packages, 
only one SDAF package includes an offer, and this offer 
includes all key pairs of the CELs included in the SDAF 
title. 

[0123] The purchase rules are described by using a 
language for describing use conditions of the key pair, 
called right management language. The use conditions 
of the key pair include the date of purchase, use period, 
and whether a specific CEL or SDAF title has been pur- 
chased or not. The purchase rules are specified by 
using these use conditions, and thereby the same CEL 
can be sold at different prices depending on the condi- 
tions. 

[0124] Next, the navigation data 2012 is described. 
The navigation data is created by a content creator so 
that the user can use the CEL most effectively, defining 
the logic structure of the SDAF title. 
[0125] In SDAF, XML (extensible Markup Lan- 
guage), which is a tag description language in a text for- 



mat, is used for describing the navigation data. When 
the data structure is described in XML. a tag structure in 
a text fonnat is used. Therefore, data described in XML 
is redundant compared with binary data. Nevertheless, 

5 XML is adopted because of its excellent expandability. 
[01 26] To refer to the CEL from the navigation data, 
a CEL locator is used. The CEL locator is a concatena- 
tion of the package ID and CELJD taking '?* (question 
mark) as a delimiter. However, for the CEL included in 

10 the SDAF package that includes the navigation data, 
the package ID and the delimiter are omitted, and the 
CELJD becomes the CEL locator. The CEL locator can 
specify the CEL independently of the physical address 
of the CEL. 

15 [01 27] FIG . 28 is a diagram showing how to refer to 
the CEL from the navigation data by using the CEL loca- 
tor. In FIG. 28, navigation data 2081 and presentation 
data 2082 are shown as an example. The presentation 
data 2082 includes an audio CEL 2083 encoded with 

20 MPEG2-AAC and an image CEL 2084 encoded with 
JPEG. The package ID and CEL^ID of the audio CEL 
2083 are both 1 , while those of the image CEL 2084 are 
1 and 2. respectively. In this case, a CEL locator "171" 
included in the navigation data 2081 indicates the audio 

25 CEL 2083 with its package ID "1" and CEL_ID "1". A 
CEL locator "1 ?2' indicates the image CEL 2084 with its 
package ID "1" and CELJD "2". As known from this 
example, only a change in the package ID of the CEL 
locator after creation of the SDAF title can cause a 

30 change in the structure of the SDAF package. There- 
fore, it is possible to structure the SDAF title as a single 
package or split the SDAF title into a plurality of SDAF 
packages. 

[0128] FIGS. 29 and 30 are diagrams showing the 

35 structure of the navigation data based on the following 
representation manner. Each rectangle represents an 
element of the navigation data. An an-ow drawn from an 
element A to an element B indicates that the element A 
includes the element B as a descendant element. Each 

40 mark provided at the start of each arrow indicates as fol- 
lows: * indicates that the element includes 0 or more 
descendant elements; + indicates that the element 
Includes 1 or more descendant elements; and ? indi- 
cates that the element includes 0 or 1 descendant ele- 

45 ment If the element A includes an item P without any 
an-ow, that means the element A has the item P as an 
attribute. Underiined items represent CEL locators. 
PCDATA represents a character string composed of 
characters included in a predetermined character set. 

50 This representation specifies a hierarchical structure 
with a TITLE element as a root. 
[0129] A TITLE element 2101 describes shipping 
information of the SDAF title. This element has three 
attributes: UPC, VERSION, and LANGUAGE. The UPC 

55 attribute describes a UPC (Universal Product Code), 
which is the International standards of product codes. 
The VERSION attribute describes the version number 
of the SDAF navigation structure. The LANGUAGE 
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attribute describes the type of language according to 
ISO 639. Its default value is "en" indicating English. 
[0130] A METADATA element 2102 describes infor- 
mation such as genre of a PLAYLIST or TRACK ele- 
ment. The METADATA element has a TYPE attribute. 
The TYPE attribute describes the type of the META- 
DATA element. 

[0131] An ASSOC element 2103 describes refer- 
ence information to a C EL included in other SDAF titles. 
This element has a REF attribute. The REF attribute 
describes the GEL locator. 

[0132] A URL element 2104 describes the URL 
(Uniform Resource Locator). This element has two 
attributes: ID and TYPE. The ID attribute describes the 
identification number of this element The TYPE 
attribute describes the type of the URL element. 
[01 33] A PLAYLIST element 21 05 describes a play- 
list, which is a basic unit for the SDAF title. The playlist 
con-esponds to an album in the conventional package 
media, and is included In all SDAF titles. The Pl_AYLIST 
element may include a MENU element, which is a menu 
for the playlist The PI_AYLIST element has five 
attributes: NAME, ARTIST, PRODUCTID. THUBMNAI- 
LID. and ONSTART. The NAME attribute describes the 
name of the playlist. The PRODUCTID attribute 
describes information con-esponding to a catalog code 
in a CD. The THUMBNAILID attribute describes the 
CEL locator of the image CEL that Is typical In the play- 
list The ONSTART attribute describes the operation for 
playing back the playlist. If the ONSTART attribute is 
"MENU", the player stops playing while displaying a 
playlist menu. If "TRACK", the player starts playing back 
the first TRACK element included in the PI-AYLIST ele- 
ment. All PLAYLIST elements have at least one TRACK 
element 21 06. 

[0134] The TRACK element 2106 describes the 
track including one audio CEL The TRACK element 
may include a track menu, slideshow, text, file, and oth- 
ers. The TRACK element has seven attributes: ID, 
NAME, ARTIST, ISRC, AUDIOID, TSMID. and THUM- 
BAILID. The ID attribute describes the identification 
number that is unique In the SDAF title. The NAME 
attribute describes the name of the TRACK element 
The ARTIST attribute describes the name of the artist 
The ISRC attribute describes ISRC (International 
Standard Recording Code). The AUDIOID attribute 
describes the CEL locator of the audio CEL related to 
the TRACK element. The TSMID attribute describes the 
CEL locator of a time search map corresponding to the 
audio CEL. The time search map will be described later. 
The THUMBNAILID attribute describes the CEL locator 
of the Image CEL that is typical In the TRACK element 
[0135] A MARKER element 2107 describes a 
marker for use in finding the start in the TRACK ele- 
ment. This element has two attributes: TIME and 
NAME. The TIME attribute describes the location of the 
marker in milliseconds. The NAME attribute describes 
the name of the marker. 



[0136] A SYNCSLIDESHOW element 2108 
describes a slideshow for displaying slides or menus by 
following display timing information specified by a SYN- 
CMAP element 2109. The SYNCSLIDESHOW element 

5 2108 has three attributes: ID, NAME, and TYPE. The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 

10 credits, lyrics, liner notes, biography, image collection, 
or promotion. 

[0137] The SYNCMAP element 21 09 describes the 
display timing information for the slide or the menu 
specified in the SYNCSLIDESHOW element The SYN- 

15 CMAP element 2109 has three attributes: MENUID. 
PLAYID, and TIME, The MENUID attribute describes 
the identification number of the slide or menu to be dis- 
played. The PLAYID attribute describes the index 
number for specifying a button to be set in a playback 

20 state on the menu. The TIME attribute describes the 
display timing in milliseconds. 

[0138] A SLIDESHOW element 21 1 0 describes the 
slideshow for displaying slides or menus at predeter- 
mined display Intervals. This element has four 

25 attributes: ID, NAME, TYPE, and INTERVAL. The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the information category in the track, such as 

30 credits, lyrics, liner notes, biography, image collection, 
or promotion. The INTERVAL attribute describes the 
display interval of the slide or menu. 
[0139] A SYNCTEXT element 2111 describes text 
information to be displayed with predetermined timing. 

35 The text information is described by using a SYNC- 
TEXTBLOCK element 21 12. Alternatively, the text infor- 
mation may be specified by referring to part of the text 
CEL. The SYNCTEXT element has four attributes: ID, 
TEXTID, REFID, and TYPE. The ID attribute describes 

40 the identification number that is unique in the SDAF titie. 
The TEXTID attribute describes the CEL locator of the 
text CEL. The REFID attribute describes the identifica- 
tion number of a TEXTREF element In the text CEL 
specified by tiie TEXTID attribute. The TEXTREF ele- 

45 ment will be described later. The TYPE attribute 
describes the information category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. 

[0140] The SYNCTEXTBLOCK element 2112 
so describes the text Information to be displayed with pre- 
determined timing. This element has a TIME attribute. 
The TIME attribute describes the display timing in milli- 
seconds. 

[01 41 ] The TEXT element 2113 describes text Infor- 
ms mation. The text Information is described in a text data 
fomnat. Alternatively, the text information may be speci- 
fied by referring to part of the text CEL. The TEXT ele- 
ment has the same types of attributes as the 
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SYNCTEXT element has. 

[0142] A VIDEO element 211 4 describes any exist- 
ing video CEL. This element has three attributes: ID, 
VIDEOID. and TYPE. The ID attribute describes the 
identification number that is unique in the SDAF title. 
The VIDEOID attribute describes the CEL locator of the 
video CEL. The TYPE attribute describes the informa- 
tion category in the traclc, such as credits, lyrics, liner 
notes, biography, image collection, or promotion. 
[0143] A FILE element 21 15 describes any existing 
file CEL. This element has three attributes: ID, FILEID. 
and TYPE. The ID attribute describes the identification 
number that is unique in the SDAF title. The FILEID 
attribute describes the CEL locator of the file CEL. The 
TYPE attribute describes the infonnation category in 
the track, such as credits, lyrics, liner notes, biography, 
image collection, or promotion. 

[0144] A SLIDE element 2116 describes a slide. 
This element has three attributes: ID, NAME, and 
BACKGROUNDID. The ID attribute describes the iden- 
tification number that is unique in the SDAF title. The 
NAME attribute describes the name of the slide. The 
BACKGROUNDID attribute describes the CEL locator 
of the image CEL on a slide screen. 
[0145] A MENU element 2117 describes a menu. 
The menu has one or more onscreen buttons. The 
MENU element has four attributes: ID, NAME, BACK- 
GROUNDID, and SELECTID. The ID attribute describes 
the identification number that is unique in the SDAF title. 
The NAME attribute describes the name of the menu. 
The BACKGROUNDID attribute describes the CEL 
locator of the image CEL displayed on a menu screen. 
The SELECTID attribute describes the index numberfor 
specifying a button to be set in a select state. 
[0146] A BUTTON element 2118 describes the 
onscreen buttons arranged on the menu screen. The 
BUTTON element includes, as descendant elements, 
one or more pairs of TEXTBUTTON and COMMAND 
elements or those of GRAPHICBUTTON and COM- 
MAND elements. The BUTTON element has seven 
attributes: INDEX, TAB. UR DOWN, RIGHT, LEFT, and 
AUTOACTION. The INDEX attribute describes the 
index number that is unique in the MENU element The 
TAB attribute describes the sequential number sequen- 
tially and circulatively provided for each of the buttons 
on the menu. The UR DOWN. LEFT, and RIGHT 
attributes describe the index number of the selected 
destination button located upward, downward, leftward, 
and rightward, respectively, from the current button. The 
AUTOACTION attribute describes the flag indicating 
whether the state is automatically changed from select 
to active. 

[0147] A TEXTBUTTON element 2119 describes 
the onscreen button represented by text. This element 
has eleven attributes: X. Y. WIDTH, HEIGHT, FORN- 
TSIZE, NORMALCOLOR. SELECTCOLOR, ACTION- 
COLOR. PLAYINGCOLOR, TEXTID, and REFID. The 
X, Y, WIDTH, and HEIGHT attributes each describe the 



display location of the button using a coordinate system 
taking the upper-left corner of the menu as the origin. 
The FONTSIZE element describes the font size in 
points. The NORMALCOLOR, SELECTCOLOR, 

5 ACTIONCOLOR. and PLAYINGCOLOR attributes 
describe a display color in RGB format when the button 
state is normal, select, active, and playback, respec- 
tively. The TEXTID attribute describes the CEL locator 
of an external text CEL. The REFID attribute describes 

10 the identification number of the TEXTREF element in 
the text CEL specified by the TEXTID. 
[0148] A GRAPHICBUTTON element 2120 
describes the onscreen button represented as graphics. 
This element has eight attributes: X. Y, WIDTH. 

15 HEIGHT. NORMALID, SELECTID. ACTIONID. and 
PLAYINGID. The X, Y, WIDTH, and HEIGHT attributes 
each describe the display location of the button using a 
coordinate system taking the upper-left corner of the 
menu as the origin. The NORMALID, SELECTID, 

20 ACTIONID, and PLAYINGID attributes each describes 
the CEL locator of the image CEL displayed when the 
button state is normal, select, active, and playback, 
respectively. 

[0149] A COMMAND element 2121 describes the 

25 navigation operation when the user presses one of the 
onscreen buttons. This element has two attributes: 
TYPE and TARGET The TYPE attribute describes any 
one of SHOW, FUNCTION, GOTO, NEXT, and PREVI- 
OUS commands. The SHOW command is for displaying 

30 the element specified by the TARGET attribute. The 
FUNCTION command is for executing the element 
specified by the TARGET attribute. This command Is 
used while a playltst menu is being displayed. The 
GOTO command is for moving from the element cur- 

35 rently displayed to a specified brother element. The 
NEXT command Is for moving from the element cur- 
rently displayed to the next brother element The PRE- 
VIOUS element is for moving from the element currently 
displayed to the previous brother element The TARGET 

40 attribute describes the parameter of the command 
specified by the TYPE attribute. If the SHOW command 
Is specified, the TARGET attribute describes the Identi- 
fication number of the element to be displayed. If the 
FUNCTION command is specified, the TARGET 

45 attribute describes the identification number of the ele- 
ment to be executed. If the GOTO command is speci- 
fied, the TARGET attribute describes the identification 
number of the brother element of the element currently 
displayed. 

50 [0150] The TEXTREF element describes text cate- 
gory information for use in referring from the navigation 
data to part of the text data stored in the text CEL. The 
text data Included in the TEXTREF element Is referred 
to by specifying the identification number of the TEX- 

55 TREF element from the navigation data. The TEXTREF 
attribute has an ID attribute. The ID attribute describes 
the identification number that is unique in the SDAF 
tittle. 
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[0151] Next, the CEL 2013 is described. The CEL 
has five types: audio, image, video, text, and file. In 
SOAR the data format and parameter are specified for 
each type of the CEL. 

[0152] The data included in the audio CEL is audio 5 
data encoded in compliance with MPEG2-AAC 
(Advanced Audio Coding) [Low Complexity Profile]. 
Note that MPEG2-AAC is specified in ISO/IEC 13818-7: 
1997(E) Information technology - Generic coding of 
moving pictures and associated audio infonnation - io 
Part7 Advanced Audio Coding (AAC). The bit stream 
encoded with MPEG2-AAC is assumed to be in the 
ADTS (Audio Data Transport Stream) format Further, 
parameters described In ISO/IEC 1381 8-7 are 
restricted as shown in FIG. 31. Of these parameters, is 
parameters other than sampnng_frequencyjndex and 
Chan neLconfigu ration are restricted due to selection of 
LC-proflle specified by ISO/IEC 13818-7. Further, the 
average bit rate is 64 or 128 kbps. 

[0153] Data included In the image CEL is image 20 
data encoded in compliance with JPEG, MPEG-I frame, 
or PNG (Portable Network Graphics). FIGS. 32, 33, and 
34 are tables showing specification of JPEG. MPEG-I 
frame, and PNG, respectively. The specifications for the 
encryption algorithms applied to the image CEL are 25 
restricted as shown in these figures. 
[0154] Data included in the video CEL is video data 
encoded in compliance with MPEG2. FIG. 35 is a table 
showing the specification of MPEG 2. The specification 
for the encryption algorithm applied to the video CEL is 30 
restricted as shown In FIG. 35. 

[0155] Data included in the text CEL is PLAIN text 
or XML text in SDAF. The encryption type is Unicode or 
music shift J IS. 

[0156] As an example of the file CEL, a time search 35 
map CEL that includes a time search map as data is 
now described. The time search map is a table com- 
posed of address of an audio frame. FIG. 36 is a dia- 
gram showing the structure of the time search map. As 
shown in FIG. 36, a time search map 2090 is composed 40 
of a header 2091 and a plurality of entries 2092. FIGS. 
37, 38a, and 38b are a table and diagrams showing the 
header 2091 in detail. As shown In FIGS. 37, 38a, and 
38b, the header 2091 includes playback duration 
between entries described in milliseconds and the total 45 
number of entries. FIG. 39 is a table showing each entry 
in detail. As shown in FIG. 39, each entry includes the 
address of the audio frame at its entry point. The first 
entry indicates the starting location of the audio frame 
included in the audio CEL. so 
[0157] Note that In the present embodiment, 
MP EG 2- AAC is used for compressing music data 
included in the audio CEL Alternatively, MP3 (MPEG1 
Audio Layer 3), Dolby-AC3. or DTS (Digital Theater 
System) may be used. ss 
[0158] Next, with reference to FIGS. 40 to 45, how 
to use the SDAF is described. As stated above, the 
SDAF Is a fomnat for describing multimedia contents. 



30 

and mainly used for musk: data distribution. The SDAF 
can be applied to various types of recording media, typ- 
ically hard disks, optical disks such as DVD- RAM, and 
semteonductor memory such as memory cards. 
[0159] In addition to music data distribution, the 
SDAF can be used in combination with the existing 
music data. For example, to be mentioned below, the 
SDAF can be used in combination with muste data com- 
plying with the DVD-Audio standards. Similarly, the 
SDAF can be applied to other recording media such as 
DVD-Video. CD, Video-CD, and Photo CD. 
[0160] Music data complying with the DVD-Audio 
standards includes LPCM (Linear Pulse Code Modula- 
tion) audio contents and MPEG-I frame Image contents. 
A player complying with the DVD-Audio standards dis- 
plays a menu screen for user's interactive operation. In 
the DVD-Audio standards, such menu screen Is dis- 
played by superimposing a maximum of four-color sub 
video images onto a background image for display and 
providing a plurality of rectangular regions in the sub 
video images. Such rectangular regions are called but- 
tons, and each button is assigned a command. How- 
ever, some restrictions are applied to the number of 
display colors and the shape of the button and therefore 
the content creator cannot freely design the menu 
screen. 

[0161] This problem can be solved by previously 
recording data of the menu screen described in the 
SDAF in a conventional DVD-Audio disk, and displaying 
the menu screen using this data at playback. More spe- 
cifically, the DVD-Audio disk records multimedia con- 
tents described In the SDAF and a CEL redirector for 
referring from the SDAF to the original DVD-Audio con- 
tents. Hereinafter, a DVD-Audio disk with such data 
recorded thereon Is called an extended DVD-Audio disk, 
and a player for playing back the extended DVD-Audio 
disk is called SDAF-compliant DVD-Audio player. 
[0162] FIG. 40 is a diagram showing an example of 
the CEL redirectors that correspond to a single DVD- 
Audio disk. Each row indicates the CEL redirector for 
each content included in the original DVD-Audio disk. 
The CEL redirector includes a CELJD 2201 , file name 
2202, start address 2203, and end address 2204. The 
CELJD 2201 Is a content identifier that is unique in the 
disk. The file name 2202 is a name of the file that 
Includes each content. The start and end addresses 
2203 and 2204 are offset values indrcating the start 
location and end location, respectively, of each content 
in the file. The CEL redirector is recorded In a file named 
DVDA.MAP, for example, in an SDAF directory provided 
in the ROM area of the extended DVD-Audio disk. 
[0163] All various playback control functions such 
as audio playback order control, slideshow image play- 
back, and a menu function defined by the DVD-Audio 
standards can be described using the SDAF navigation 
data. For example, the menu function can be realized by 
superimposing JPEG button images having any number 
of colors and shape onto an MPEG-I frame background 
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image for cfisplay and relating each button region to a 
command. 

[01641 When playback control information Included 
in the DVD-Audio disk is converted into SDAF naviga- 
tion data, information indicating a content is converted 
into the CELJD by using the CEL redirector. The menu 
screen is converted into JPEG button images. The 
obtained images are arranged at locations so as to be 
superimposed onto the background image. The naviga- 
tion data and button images as obtained in the above 
described manner are stored in a single SDAF package, 
and recorded in a file named SDAF.SDP. for example, in 
an SDAF directory provided in ttie ROM region of the 
extended DVD-Audio disk. The method of playing back 
the extended DVD-Audio disk will be described later. 
[0165] Next, an SDAF player for playing back multi- 
media contents described with SDAF is described 
below. The SDAF player plays back distributed music 
data in the following manner. First, ttie player searches 
forthe package IDs and navigation information to collect 
the CELJDs of the CELs required for playback. The 
player searches purchase database using sets of the 
collected package ID and CEL_ID to detemnine whether 
each CEL has been purchased or not. If any CEL not 
yet purchased is found, the player analyzes the 
encoded offer, and pays a predetermined price through 
the existing electronic distribution system. After pur- 
chasing, the key pair stored in the offer is stored in the 
purchase database. If detemnining that the SDAF pack- 
age required for playback is not found in the player, the 
player sends out the package ID to the data distribution 
apparatus. The data distribution apparatus distributes 
an SDAF package with the received package ID to the 
player. After purchasing all CELs required for playback, 
the player decrypts the CELs using the key pairs stored 
in the purchase database for playback. At this time, the 
player interprets the navigation data for playback con- 
trol. ^ . 
[0166] The SDAF title is distributed to the player as 
being split into one or more SDAF packages. FIGS. 41a 
to 41 c are diagrams showing examples how to distribute 
the SDAF packages. In a distribution method as shown 
in FIG. 41a, a package 2301 includes only an audio 
content, while a package 2302 includes only an image 
or video graphic content. Moreover, from the package 
2302, the audio content included in the package 2301 is 
refen-'ed to. Therefore, the user who purchased only the 
package 2301 can play back only the audio content 
The user who purchased the package 2302 in addition 
to the package 2301 can play back the graphic content 
together with the audio content As such, the SDAF title 
may be specified by adding a CEL to the existing track. 
[0167] In a distribution method as shown in FIG. 
41b, a package 2303 includes a plurality of audio con- 
tent's and graphic contents. As such, a single package 
may include all CELs included in the SDAF title. 
[0168] In a distribution method as shown in FIG. 
41c, a single SDAF title is split into packages 2304. 



2305. and 2306 for distribution. The package 2305 
includes a content for Track #1 . while the package 2306 
includes a content for Track #2. In this distribution 
method, it is possible to select either one of the pack- 
5 ages 2305 and 2306 for distribution. 

[0169] Moreover, in the player, a new SDAF pack- 
age including a content owned by the user may be cre- 
ated. FIGS. 42a to 42c are diagranr^ showing examples 
how to create SDAF packages. In FIGS. 42a to 42c, a 
10 user package is an SDAF package created by the user, 
while a purchased package is a distributed SDAF pack- 
age. Contents surrounded by a thick line are owned by 
the user. It is assumed herein that the user owns data 
read from a CD, that Is, an audio content ripped from the 
15 CD, and a graphte content created by himself/herself. 
[0170] As shown in FIG. 42a. the user may create a 
package 2401 including the audio content owned by 
himself/herself. Furthemnore. as shown in FIG. 42b. the 
user may create a package 2402 including the audio 
20 and graphic contents owned by hinnself/herseif. Still fur- 
ther, as shown in FIG. 42c, the user may create a pack- 
age 2404 from which the audio content included in the 
purchased package 2403 is referred to. If the package 
2404 is played back, the audio content included in ttie 
25 purchased package and the graphic content owned by 
the user are played back. Therefore, the image included 
in the purchased package can be changed to the image 
created by the user, or a new image created by the user 
can be added to the purchased package. 
30 [0171] Next, the SDAF-compliant DVD-Audio player 
for playing back the extended DVD-Audio disk is 
described. The player controls playback operation by 
following the navigation data described with SDAF 
instead of the original playback control information com- 
as plying with the DVD-Audio standards. The player reads 
the navigation data and the CEL locator from the 
extended DVD-Audio disk, and operates by following 
the read navigation data. If the original audio content or 
image content is refen-ed to from the navigation data, 
40 the player refers to the CEL locator to obtain information 
about the location in which the content is stored, and 
plays back the content The player reads ttie back- 
ground image from the DVD-Audio region on the disk 
and the button images from the SDAF data, and com- 
45 bines them to display the menu screen. 

[0172] As such, with the use of the extended DVD- 
Audio disk, the existing DVD-Audio player can cany out 
conventional playback, while the SDAF^mpliant DVD- 
Audio player can display the menu screen by using ttie 
50 navigation data described with SDAR 

[0173] In the above description, the SDAF package 
and CEL redirector are stored in the disk. Alternatively, 
such data may be downloaded through a network to ttie 
player. This metiiod can be applied to CDs and DVD 
55 disks tiiat have already been sold to the user. Further- 
more, with this method, the CELs ttiat are accessible 
through a communteation networic can be refenred to by 
using the URL. 
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[0174] Next, a data conversion apparatus for copy- 
ing multimedia contents specified in SDAF to an exter- 
nal storage medium for portable music players is 
described. Here, the portable music player Is structured 
by using semiconductor memory as an external storage 
medium, and characterized by its small size, light 
weight, and capability of writing data therein at high 
speed. The portable music player includes, as shown in 
FIG. 43, a liquid crystal display 2501 capable of display- 
ing text, a control panel 2502 for controlling audio play- 
back, and a headphone 2503 for audio output 
Furthermore, a memory card 2500 for storing audio 
data can be removably attached to the portable music 
player. The portable music player plays back audio con- 
tents complying with MPEG2-AAC, and also displays 
text information. However, the data recording fomnat of 
the memory card is not SDAF. but a unique format 
[0175] FIG. 44 is a block diagram showing the 
structure of the data conversion apparatus for convert- 
ing contents recorded on an extended DVD-Audio disk 
into a predetermined fomnat, and writing the converted 
contents in a memory card for portable music players. In 
FIG. 44, it is assumed that an LPCM-format audio con- 
tent, an image content In MPEG-1 frame fomnat, play- 
back control information described with SDAF, and 
additional text information are recorded in a disk 2601 . 
[0176] In the data conversion apparatus shown in 
FIG. 44. a data read unit 2602 reads the playback con- 
trol information from the disk 2601, and provides the 
same to a playback control information analyzing unit 
2603. The playback control information analyzing unit 
2603 analyzes the read playback control information to 
examine whether the content recorded on the disk 2601 
can be played back or requires conversion. 
[0177] Next, the data read unit 2602 sequentially 
reads, from the disk 2601, contents that can be played 
back by the portable music player, and provides the 
read contents to a data conversion unit 2605. At this 
time, contents that cannot be played back by the porta- 
ble music player is not read. The data conversion unit 
V 2605 converts the read contents according to the type 
of a memory card 2500. For example, text infomriation 
that can be directly played back by the portable music 
player such as titles is not converted. On the other hand, 
tPCM-format audio contents are converted into 
MPEG2-AAC fonnat so that the portable music player 
can play back the contents. 

[0178] The playback control infomiation conversion 
unit 2604 generates playback control Information for the 
portable music player based on the playback control 
infomiation analyzed by the playback control informa- 
tion analyzing unit 2603. A data write unit 2606 writes 
the playback control information generated by the play- 
back control information conversion unit 2604 and the 
contents converted by the data conversion unit 2605 in 
the memory card 2500. 

[0179] Note that, the data conversion unit shown in 
FIG. 44 may convert arbitrary contents other than audio 



contents Into a predetermined format and write the con- 
verted contents in the memory card 2500. Furthermore, 
the data recording format of the memory card may be 
an arbitrary format other than SDAF. Still further, for 

5 supporting a plurality of external storage media, the 
data conversion apparatus may include the data conver- 
sion unit, playback control information conversion unit, 
and data write unit for each external storage medium. 
[0180] Moreover, If no navigation data described 

70 with SDAF is recorded on the disk 2601, as shown in 
FIG. 45, lacking data may be obtained through a com- 
munication network. In FIG. 45, it is assumed that an 
identtficatton number is recorded in the disk 2601. For 
example, the Identification number of a muste CD is a 

IS catalog code, ISRC code, and others. 

[01 81 ] The data read unit 2602 reads the identifica- 
tion number of the disk, and provides the same to a 
communication unit 2607. The communication unit ^ 
2607 communteates with a content infomnation server 

20 261 1 through a communication network 261 0. The com- 
munication unit 2607 may access to the content infor- 
mation server 26 11 through the internet, or may directly 
access the content Information server 261 1 through a 
telephone circuit. The content infonnation server 261 1 

25 stores the lacking data in relation to the identification 
number, and In response to a request from a data con- 
version apparatus, sends the lacking data to the data 
conversion apparatus. After receiving the tacking data, 
the data conversion apparatus carries out the same 

30 Operation as the data conversion apparatus as shown In 
FIG. 44, 

[01 82] As stated above, the content distribution for- 
mat SDAF according to the present embodiment is a 
format for describing multimedia contents, and mainly 

35 used for music data distribution. Also, using the SDAF In 
combination with the existing music data can extend the 
function of the existing music data. 
[0183] Note that, as known from the comparison 
between FIGS. 3 and 1 8, the correlation between the 

40 music data described In the first to third embodiments 
and the SDAF according to the present embodiment Is 
as follows. That is, the header 40 shown In FIG. 3 con-e- 
sponds to the header 201 1 shown in FIG. 1 8. The navi- 
gation Infomnation 41 shown in FIG. 3 corresponds to 

45 the navigation data 2012 shown In FIG. 1 8. The content 
42 shown In FIG. 3 corresponds to the GEL 201 3 shown 
in FIG. 18. The billing information 43 shown in FIG. 3 
corresponds to the offer 2014 shown in FIG. 18. 
[0184] While the invention has been described in 

50 detail, the foregoing description is in all aspects illustra- 
tive and not restrkrtive. It is understood that numerous 
other modifications and variations can be devised with- 
out departing from the scope of the invention. 

55 (Fourth Embodiment) 

[0185] As the fourth embodiment, as a specific 
example of copyrighted data as mentioned in the first to 
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third einbodiments. a content distribution format called 
SDAF (Secure Digital Audio Format) Is described below. 
Referring to FIGS. 18 to 39. details on the SDAF is first 
described, and then referring to FIGS. 40 to 45, how to 
use the SDAF Is described. 5 
[0186] The content distribution format (SDAF) 
according to the present embodiment is used for 
describing multimedia contents that include audio, 
images, video, text, and file data. The multimedia con- 
tents described with SDAF are herein called an SDAF io 
title. Presentation data each comprising the SDAF title 
is herein called a content element (hereinafter abbrevi- 
ated as CEL). Each CEL is assigned a CEL identifier 
that is unique in the SDAF title (hereinafter abbreviated 
as CELJD). 15 
[0187] The SDAF title Is distributed as being split 
into units called SDAF packages. Each SDAF package 
is assigned a package identifier that is unique In the 
entire distribution system. FIG. 18 is a diagram showing 
an example of the SDAF package. As shown in FIG. 18, 20 
an SDAF title 2000 is composed of a plurality of SDAF 
packages. Each package 2001 is composed of a header 
2011, navigation data 2012, a plurality of CELs 2013, 
and an offer 201 4. 

[0188] The header 201 1 includes information such 25 
as location, size, and attribute of each data in the pack- 
age. Such information defines the package structure. 
The navigation data 2012 Is playback control informa- 
tion specifying the operation of the player in playing 
back the SDAF title. From the navigafion data 2012, a 30 
CEL included in the package to which the navigation 
data belong or In other packages is referred to. The CEL 
2013 is obtained by encrypting each presentation data 
composing the SDAF title, and more specifically, by 
encrypting audio, images, video, text, or file data. A pair 35 
of a decryption key for decrypting the CEL 2013 and 
CELJD is called a key pair. The offer 2014 includes a 
plurality of key pairs, and purchase rules describing the 
purchase price and available period for each key pair. 
[0189] FIGS. 19a to 19c are diagrams showing 40 
three types of SDAF packages. A full package 2001 
shown In FIG. 19c includes, similariy to FIG. 18, a 
header 201 1 , navigation data 2012. a plurality of CELs 
2013, and an offer 2014. An offer package 2002 shown 
in FIG. 19a includes the header 2011, the navigation 45 
data 2012, and the offer 2014. but does not include any 
CEL 2013. A CEL package 2003 shown in FIG. 19b 
includes the header 2011 and the plurality of CELs 
2013. Since the navigafion data 2012 is required for 
playing back the SDAF title, the full package 2001 and so 
the offer package 2002 can be played back alone, but 
the CEL package 2003 cannot 
[0190] The CEL package is used for splitting the 
SDAF title according to the distribution channel. For 
example, when distributed by using a CD-ROM, the ss 
SDAF title is recorded as a full package in the CD-ROM. 
On the other hand, when distributed through the Inter- 
net, the SDAF title is split into one full package and a 
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plurality of CEL packages for distribution. For example, 
the SDAF title is split into one full package including an 
audio CEL and a plurality of CEL packages including a 
video CEL that Is referred to from the full package for 
distribution. 

[0191] Further, as shown in FIG. 20. the SDAF title 
may be split into a plurality of SDAF packages by tracks. 
In package division as shown in FIG. 20, an SDAF titie 
2020 including audio data for five tracks is split into 
three packages 2021 to 2023. The first to third pack- 
ages 2021 to 2023 have package names Singtel. 
Single2, and album, respectively. The first and second 
packages 2021 and 2022 both include an audio CEL for 
one track and navigation data for controlling playback of 
the CEL. The third package 2023 includes an audio 
CEL for three tracks and navigation data for controlling 
playback of all audio CELs included in the first to third 
packages 2021 to 2023. As such, by dividing the SDAF 
title into a plurality of SDAF packages, it is possible to 
make each data size smaller and easily handle each 
data. 

[0192] The header, offer, navigation data, and CEL. 
which compose the SDAF package, are described in 
this order below. 

[0193] The header 201 1 Is first described. Here, an 
SDAF package shown In FIG. 21 is taken as an exam- 
ple, and a header 2031 of an SDAF package 2030 is 
described. In the SDAF package 2030. it is herein 
assumed that the size of navigation data 2032 and the 
size of an offer 2034 are 400H each, in hexadecimal 
notation. This package Includes three CELs 2033. and 
the types thereof are, from first, audio, image, and file. It 
is assumed here in that the sizes of these CELs are, 
from first, 400000H, 18000H, and 8000H in hexadeci- 
mal notation. 

[0194] FIG. 22 is a diagram showing the structure of 
the header 2031 . In the header 2031 . data as described 
below is sequentially stored, and the size of the header 
is BCH in hexadecimal notation. Note that the structure 
of the header 2031 can be described in the C-m- lan- 
guage as shown in FIGS. 23 and 24. FIGS. 23 and 24 
are a diagram showing a sequential source code as 
being split into two, and before division, a source code 
2062 shown in FIG. 24 follows a source code 2061 
shown in FIG. 23. 

[0195] At the start of the header 2031, a magic 
number 2041 (4 bytes) indicating that the file is in the 
SDAF format is stored. The value of the magic number 
2041 is a character string "SDAF". Then, a version 
number 2042 (4 bytes) of the SDAF is stoned. Then, a 
package ID 2043 (1 6 bytes) and a package size 2044 (4 
bytes) are stored. Then, navigation data location infor- 
mation 2045 (SDAF_LOCATION„NAV in FIG. 23), offer 
location infomriation 2046 (SDAF_L0CATION_OFFER 
in FIG. 23), and the number of CELs in the package 
2047 are stored- Then, CEL Information 2048 
(SDAF_LOCATION_CEL in FIG. 24) for each CEL is 
stored. Lastly, a CEL attribute table 2049 indicating an 
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attribute of each CEL is stored. 

[0196] The navigation data location infomnation 
2045 indicates the location and size of the navigation 
data 2032. The offer location infomnation 2046 indicates 
the location and size of the offer 2034. These two pieces s 
of information are both composed of an offset (4 bytes) 
from the start of the SDAF package and each size (4 
bytes) thereof. 

[0197] The CEL information 2048 is composed of a 
CEL.ID 2051 (16 bytes), a CEL type 2052 (2 bytes), a io 
CEL encryption type 2053 (2 bytes), a CEL data loca- 
tion information 2054, and a CEL attribute table location 
infonnation 2055. The CEL_ID 2051 is a content ele- 
ment identifier that is unique in the SDAF title. The CEL 
type 2052 takes any value of audio, image, video, text, is 
and file. The CEL encryption type 2053 indicates an 
algorithm used for encrypting the CEL. The CEL data 
location Information 2054 and CEL attribute table loca- 
tion information 2055 are both composed of an offset (4 
bytes) from the start of the SDAF package and each 20 
size (4 bytes) thereof. If the offset or size is 0, that 
means no data exists. 

[0198] The CEL attribute table 2049 is a list of 
attributes specified for each CEL type. An audio CEL 
attribute table (SADF_ATTR_AUDIO in FIG. 24) 25 
includes at least CODEC, the number of quantized bits, 
sampling frequency, and the number of audio channels. 
An image CEL attribute table {SDAF_ATTR_GRAPHIC 
in FIG. 24). includes at least the height and width of the 
image and the encryption type. A video CEL attribute 30 
table includes at least the height and width of the video 
and the encryption type. A text attribute table Includes at 
least the encryption type of the text, such as Unicode or 
music shift J IS (Japanese Industrial Standards). A file 
CEL attribute table Includes at least the type of MIME 35 
(Multipurpose Internet Message Extension). 
[0199] The CEL attribute table 2049 is defined not 
as a fixed-length table but with a variable-length tag 
structure as shown in FIGS. 25a to 25c. If the tag struc- 
ture is used, a tag length and tag ID are stored preced- 40 
ing the data, as shown in FIG. 25a. For example, the 
image CEL attribute table is composed of a characteris- 
tic tag 2063 and an encryption type tag 2064. The table 
elements are specified by using the tag structure, 
thereby a new table element can be added to the data 45 
format or the data format can be changed only by add- 
ing a tag. The CEL attribute table is specified by using 
the tag structure with a great potential for expansion. 
[0200] Next, the offer 2014 is described. As stated 
above, the offer includes a plurality of key pairs and pur- 50 
chase rules for each key pair. Each key pair is com- 
posed of a decryption key for decrypting the CEL and a 
CELJD. FIG. 26 is a diagram showing the correspond- 
ence between the key pair and the CEL. As shown in 
FIG. 26, a key pair 2072 is composed of a decryption 55 
key 2073 and a CEL_ID 2074, and each key pair 2072 
is related to each CEL 2071. The offer Includes not only 
the key pair of the CEL included In the SDAF package 



but also all key pairs of the CELs included In the SDAF 
packages of the same SDAF title. In other words, when 
one SDAF title is split into a plurality of SDAF packages, 
only one SDAF package Includes an offer, and this offer 
includes ail key pairs of the CELs included in the SDAF 
title. 

[0201] The purchase rules are described by using a 
language for describing use conditions of the key pair, 
called right management language. The use conditions 
of the key pair include the date of purchase, use period, 
and whether a specific CEL or SDAF title has been pur- 
chased or not The purchase rules are specified by 
using these use conditions, and thereby the same CEL 
can be sold at different prices depending on the condi- 
tions. 

[0202] Next, the navigation data 2012 is described. 
The navigation data is created by a content creator so 
that the user can use the CEL most effectively, defining 
the logic structure of the SDAF title. 
[0203] In SDAF. XML (extensible Markup Lan- 
guage), which is a tag description language In a text for- 
mat, is used for describing the navigation data. When 
the data structure is described in XML, a tag structure in 
a text format is used. Therefore, data described In XML 
is redundant compared with binary data. Nevertheless, 
XML is adopted because of its excellent expandability. 
[0204] To refer to the CEL from the navigation data, 
a CEL locator is used. The CEL locator Is a concatena- 
tion of the package ID and CELJD taking '?' (question 
mark) as a delimiter. However, for the CEL included in 
the SDAF package that Includes the navigation data, 
the package ID and the delimiter are omitted, and the 
CELJD becomes the CEL locator. The CEL locator can 
specify the CEL independently of the physical address 
of the CEL. 

[0205] FIG. 28 is a diagram how to refer to the CEL 
from the navigation data by using the CEL locator. In 
FIG. 28, navigation data 2081 and presentation data 
2082 are shown as an example. The presentation data 

2082 includes an audio CEL 2083 encoded with 
MPEG2-AAC and an image CEL 2084 encoded with 
JPEG. The package ID and CEL_1D of the audio CEL 

2083 are both 1, while those of the Image CEL 2084 are 
1 and 2, respectively. In this case, a CEL locator "1?1" 
included in the navigation data 2081 indicates the audio 
CEL 2083 with Its package ID "1" and CEL_ID "1". A 
CEL locator "1 ?2" indicates the image CEL 2084 with its 
package ID "1" and CEL_ID "T. As known from this 
example, only a change in the package ID of the CEL 
locator after creation of the SDAF title can cause a 
change in the structure of the SDAF package. There- 
fore, it is possible to structure the SDAF title as a single 
package or split the SDAF title into a plurality of SDAF 
packages. 

[0206] FIGS. 29 and 30 are diagrams showing the 
structure of the navigation data based on the following 
representation manner. Each rectangle represents an 
element of the navigation data. An arrow drawn from an 
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element A to an element B indicates that the element A 
includes the element B as a descendant element Each 
mark provided at the start of each an-ow indicates as fol- 
lows: * indicates that the element includes 0 or more 
descendant elements; + indicates that the element 
includes 1 or more descendant elements; and ? indi- 
cates that the element includes 0 or 1 descendant ele- 
ment, if the element A includes an item P without any 
arrow, that means the element A has the item P as an 
attribute. Underlined items represent CEL locators. 
PCDATA represents a character string composed of 
characters included in a predetemiined character set 
This representation specifies a hierarchical structure 
with a TITLE element as a root. 
[0207] A TITLE element 2101 describes shipping 
information of the SDAF title. This element has three 
attributes: UPC, VERSION, and LANGUAGE. The UPC 
attribute describes a UPC (Universal Product Code), 
which is the international standards of product codes. 
The VERSION attribute describes the version number 
of the SDAF navigation structure. The LANGUAGE 
attribute describes the type of language according to 
ISO 639. Its default value is "en" indicating English. 
[0208] A METADATA element 21 02 describes infor- 
mation such as genre of a PLAYLIST or TRACK ele- 
ment. The METADATA has a TYPE attribute. The TYPE 
attribute describes the type of the METADATA element 
[0209] An ASSOC element 2103 describes refer- 
ence information to a CEL included in other SDAF title. 
This element has a REF attribute. The REF attribute 
describes the CEL locator. 

[0210] A URL element 2104 describes the URL 
(Uniform Resource Locator). This element has two 
attributes: ID and TYPE. The ID attribute describes the 
identification number of this element The TYPE 
attribute describes the type of the URL element 
[0211] A PLAYLIST element 2105 describes a play- 
list, which is a basic unit for the SDAF title. The playlist 
corresponds to an album in the conventional package 
media, and included in all SDAF titles. The PLAYLIST 
element may include a MENU element, which a menu 
for the playlist The PLAYLIST element has five 
attributes: NAME, ARTIST. PRODUCTID, THUBMNAI- 
LID, and ONSTART. The NAME attribute describes the 
narne of the playlist TTie PRODUCTID attribute 
describes information con-esponding to a catalog code 
in a CD. The THUMBNAILID attribute describes the 
CEL locator of the image CEL ttiat is typical in the play- 
list The ONSTART attribute describes the operation fo; 
playing back the playlist. If the ONSTART attribute is 
"MENU", the player stops playing while displaying a 
playlist menu. If TRACK", the player starts playing back 
the first TRACK element included in the PLAYLIST ele- 
ment. All PLAYLIST elements have at least one TRACK 
element 2106. 

[0212] The TRACK element 2106 describes the 
track including one audio CEL The TRACK element 
may include a track menu, slideshow, text, file, and oth- 



ers The TRACK element has seven attributes: ID. 
NAME, ARTIST, ISRC. AUDIOID, TSMID, and THUM- 
BAILID. The ID attribute describes the identification 
number ttiat Is unique in ttie SDAF title. The NAME 
5 attribute describes the name of the TRACK element. 
The ARTIST attribute describes the name of the artist. 
The ISRC attribute describes ISRC (International 
Standard Recoreling Code). The AUDIOID attribute 
describes the CEL locator of the audio CEL related to 
to the TRACK element The TSMID attribute describes the 
CEL locator of a time search map corresponding to the 
audio CEL The time search map will be described later. 
The THUMBNAILID attribute describes the CEL locator 
of the image CEL that is typical in the TRACK element. 
15 [0213] A MARKER element 2107 describes a 
marker for use in finding the start in the TRACK ele- 
ment TTils element has two attributes: TIME and 
NAME. The TIME attribute describes the location of the 
maricer in milliseconds. The NAME attribute describes 
20 the name of the marker. 

[0214] A SYNCSLIDESHOW element 2108 
describes a slideshow for displaying a slide or menu by 
following display timing information speeded by a SYN- 
CMAP element 2109. The SYNCSLIDESHOW element 
25 21 08 has three attributes: ID, NAME, and TYPE. The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the infomnation category in the track, such as 
30 credits, lyrics, liner notes, biography, image collection, 
or promotion. 

[0215] The SYNCMAP element 2109 describes the 
display timing infomnation for the slide or the menu 
specified in the SYNCSLIDESHOW element The SYN- 
35 CMAP element 2109 has three attributes: MENUID, 
PLAYID, and TIME. The MENUID attribute describes 
the identification number of the slide or menu to be dis- 
played. The PLAYID attribute describes the index 
number for specifying a button to be set in a playback 
40 state on the menu. The TIME attribute describes the 
display timing in milliseconds. 

[0216] A SLIDESHOW element 21 1 0 describes the 
slideshow for displaying slides or menu at predeter- 
mined display intervals. This element has four 
45 attributes: ID, NAME. TYPE, and INTERVAL The ID 
attribute describes the identification number that is 
unique in the SDAF title. The NAME attribute describes 
the name of the slideshow. The TYPE attribute 
describes the infomnation category in the track, such as 
50 credits, lyrics, liner notes, biography, image collection, 
or promotion. The INTERVAL attribute describes ttie 
display interval of the slide or menu. 
[0217] A SYNCTEXT element 21 1 1 describes text 
information to be displayed with predetemnined timing. 
55 The text information is described by using a SYNC- 
TEXTBLOCK element 21 12. Alternatively, the text infor- 
mation may be specified by refen-ing to part of the text 
CEL. The SYNCTEXT element has four attributes: ID, 
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TEXTID, REFID, and TYPE. The ID attribute describes 
the identification number that is unique in the SDAF title. 
The TEXTID attribute describes the C EL locator of the 
text CEL. The REFID attribute describes the identifica- 
tion number of a TEXTREF element in the text CEL 5 
specified by the TEXTID attribute. The TEXTREF ele- 
ment will be described later. The TYPE attribute 
describes the infomnation category in the track, such as 
credits, lyrics, liner notes, biography, image collection, 
or promotion. w 
[0218] The SYNCTEXTBLOCK element 2112 
describes the text infomiation to be displayed with pre- 
determined timing. This element has a TIME attribute. 
The TIME attribute describes the display timing in milli- 
seconds. 15 
[021 9] The TEXT element 2113 describes text infor- 
mation. The text information is described in a text data 
format. Alternatively, the text infomnation may be speci- 
fied by refemng to part of the text CEL. The TEXT ele- 
ment has the same types of attributes as those of the 20 
SYNCTEXT element. 

[0220] A VIDEO element 2114 describes any exist- 
ing video CEL. This element has three attributes: ID. 
VIDEOID. and TYPE. The ID attribute describes the 
identification number that is unique In the SDAF title. 25 
The VIDEOID attribute describes the CEL locator of the 
video CEL. The TYPE attribute describes the informa- 
tion category in the track, such as credits, lyrics, liner 
notes, biography, image collection, or promotion. 
[0221] A FILE element 21 15 describes any existing 30 
file CEL. This element has three attributes: ID, FILEID, 
and TYPE. The ID attribute describes the identification 
number that is unique in the SDAF title. The FILEID 
attribute describes the CEL locator of the file CEL. The 
TYPE attribute describes the information category in 35 
the track, such as credits, lyrics, liner notes, biography, 
image collection, or promotion. 

[0222] A SLIDE element 2116 describes a slide. 
This element has three attributes: ID, NAME, and 
BACKGROUNDID. The ID attribute describes the iden- 40 
tification number that is unique in the SDAF title. The 
NAME attribute describes the name of the slide. The 
BACKGROUNDID attribute describes the CEL locator 
of the image CEL on a slide screen. 

[0223] A MENU element 2117 describes a menu. 45 
The menu has one or more onscreen buttons. The 
MENU element has four attributes: ID. NAME. BACK- 
GROUNDID, and SELECTID. The ID attribute describes 
the identification number that is unique In the SDAF title. 
The NAME attribute describes the name of the menu, so 
The BACKGROUNDID attribute describes the CEL 
locator of the image CEL displayed on a menu screen. 
The SELECTID attribute describes the index number for 
specifying a button to be set in a select state. 
[0224] A BUTTON element 2118 describes the ss 
onscreen buttons arranged on the menu screen. The 
BUTTON element includes, as descendant elements, 
one or more pairs of TEXTBUTTON and COMMAND 
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elements or those of GRAPHICBUTTON and COM- 
MAND elements. The BUTTON element has seven 
attributes: INDEX. TAB, UP. DOWN, RIGHT, LEFT, and 
AUTOACTION. The INDEX attribute describes the 
number that is unique in the MENU element The TAB 
attribute describes the sequential number sequentially 
provided for each of the buttons on the menu. The UP. 
DOWN, LEFT, and RIGHT attributes describe the Index 
number of the selected destination button located 
upward, downward, leftward, and rightward, respec- 
th^ely, from the current button. The AUTOACTION 
attribute describes the flag indicating whether the state 
is automatically changed from select to active. 
[0225] The TEXTBUTTON element 21 1 9 describes 
the onscreen button represented by text. This element 
has eleven attributes: X, Y, WIDTH, HEIGHT, FORN- 
TSIZE. NORMALCOLOR, SELECTCOLOR, ACTION- 
COLOR, PLAYINGCOLOR. TEXTID, and REFID. The 
X, Y, WIDTH, and HEIGHT attributes each describe the 
display location of the button using a coordinate system 
taking the upper-left corner of the menu as the origin. 
The FONTS IZE element describes the font size in 
points. The NORMALCOLOR. SELECTCOLOR, 
ACTIONCOLOR, and PLAYINGCOLOR attributes 
describe a display color In RGB format when the button 
state is normal, select, active, and playback, respec- 
tively. The TEXTID attribute describes the CEL locator 
of an external text CEL. The REFID attribute describes 
the identification number of the TEXTREF element in 
the text CEL specified by the TEXTID. 
[0226] The GRAPHICBUTTON element 2120 
describes the onscreen button represented as graphics. 
This element has eight attributes: X, Y, WIDTH, 
HEIGHT, NORMALID, SELECTID. ACTIONID, and 
PLAYINGID. The X, Y, WIDTH, and HEIGHT attributes 
each describe the display location of the button using a 
coordinate system taking the upper-left comer of the 
menu as the origin. The NORMALID, SELECTID. 
ACTIONID, and PLAYINGID attributes each describes 
the CEL locator of the image CEL displayed when the 
button state is normal, select, active, and playback, 
respectively. 

[0227] The COMMAND element 2121 describes 
the navigation operation when the user presses one of 
the onscreen buttons. This element has two attributes: 
TYPE and TARGET. The TYPE attribute describes any 
one of SHOW. FUNCTION, GOTO, NEXT, and PREVI- 
OUS commands. The SHOW command is for displaying 
the element specified by the TARGET attribute. The 
FUNCTION command is for executing the element 
specified by the TARGET attribute. This command is 
used while a playlist menu Is being displayed. The 
GOTO command Is for moving from the element cur- 
rently displayed to a specified brother element The 
NEXT command is for moving from the element cur- 
rently displayed to the next brother element The PRE- 
VIOUS element is for moving from the element currently 
displayed to the previous brother element The TARGET 
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attribute describes the parameter of the command 
specified by the TYPE attribute. If the SHOW command 
is specified, the TARGET attribute describes the identi- 
fication number of the element to be displayed. If the 
FUNCTION command is specified, the TARGET 
attribute describes the identification number of the ele- 
ment to be executed, if the GOTO command is speci- 
fied, the TARGET attribute describes the identification 
number of the brother element of the element currently 
displayed. 

[0228] The TEXTREF element describes text cate- 
gory information for use in referring from the navigation 
data to part of the text data stored in the text CEL. The 
text data included in the TEXTREF element is refen-ed 
to by specifying the identification number of the TEX- 
TREF element from the navigation data. The TEXTREF 
attribute has an ID attribute. The ID attribute describes 
the identification number that Is unique in the SDAF 
tittle. 

[0229] Next, the CEL 2013 is described. The CEL 
has five types: an audio CEL, image CEL, video CEL, 
text CEL, and file CEL. In SDAF, the data format and 
parameter are specified for each type of the CEL. 
[0230] The data included In the audio CEL is audio 
data encoded \ as complying with MPEG2-AAC 
(Advanced Audio Coding) [Low Complexity Profile]. 
Note that MPEG2-AAC is specified in ISO/IEC 1381 8-7: 
1997(E) Information technology - Generic coding of 
moving pictures and associated audio information - 
Part7 Advanced Audio Coding (AAC). The bit stream 
encoded with MPEG2-AAC is assumed to be in the 
ADTS (Audio Data Transport Stream) format Further, 
parameters described in ISO/IEC 1 381 8-7 are 
restricted as shown in FIG. 31 . Of these parameters, 
parameters other than sampling_frequencyjndex and 
channeLconfiguration are restricted due to selection of 
LC-profile specified by ISO/IEC 13818-7. Further, the 
average bit rate is 64 or 126 kbps. 
[0231] Data included in the image CEL is image 
data encoded as complying with JPEG, MPEG-I frame, 
PNG (Portable Network Graphics). FIGS. 32. 33 and 34 
are tables showing specification of JPEG, MPEG-I 
frame and PNG. The specifications for the encryption 
algorithms applied to the Image CEL are restricted as 
shown in these drawings. 

[0232] Data included in the video CEL is video data 
encoded as complying with MPEG2. FIG. 35 is a table 
showing the specification of MPEG 2. The spedficafion 
for the encryption algorithm applied to the video CEL is 
restricted as shown in FIG. 35. 

[0233] Data included In the text CEL is PLAIN text 
or XML text In SDAF. The encryption type is Unicode or 
music shift JIS. 

[0234] As an example of the file CEL, a time search 
map CEL that includes a time search map as data is 
now described. The time search map is a table com- 
posed of address of an audio frame. FIG. 36 is a dia- 
gram showing the structure of the time search map. As 



shown in FIG. 36, a time search map 2090 is composed 
of a header 2091 and a plurality of entries 2092. FIGS. 
37, 38a. and 38b are a table and diagrams showing the 
header 2091 In detail. As shown in FIGS. 37, 38a. and 

5 38b, the header 2091 includes playback time between 
entries described in milliseconds and the total number 
of entries. FIG. 39 is a table showing each entry in 
detail. As shown in FIG. 39. each entry includes the 
address of the audio frame at its entry point. The first 

10 entry indicates the starting location of the audio frame 
Included in the audio CEL. 

[0235] Note that in the present embodiment, 
MPEG2-/^AC is used for compressing music data 
Included In the audio CEL. Altematively, MP3 (MPEG1 
15 Audio Layer 3), Dolby-AC3, or DTS (Digital Theater 
System) may be used. 

[0236] Next, with reference to FIGS. 40 to 45, how 
to use the SDAF is described. As stated above, the 
SDAF is a format for describing multimedia contents, 

20 and mainly used for music data distribution. The SDAF 
can be applied to various types of recording media, typ- 
ically hard disks, optical disks such as DVD- RAM. and 
semiconductor memory such as memory cards. 
[0237] In addition to music data distribution, the 

25 SDAF can be used in combination with the existing 
music data. For example, as will mentioned below, the 
SDAF can be used in combination with music data com- 
plying with the DVD-Audio standards. Similarly, the 
SDAF can be applied to other recording media such as 

30 DVD-Video. CD. Video-CD. and Photo CD. 

[0238] Music data complying with the DVD-Audio 
standards includes LPCM (Linear Pulse Code Modula- 
tion) audio contents and MPEG-I frame image contents. 
A player complying with the DVD-Audio standards dis- 
ss plays a menu screen for user's Interactive operation. In 
the DVD-Audio standards, such menu screen is dis- 
played by superimposing a maximum of four sub video 
images onto a background image for display and provid- 
ing a plurality of rectangular regions in the sub video 

40 images. Such rectangular regions are called buttons, 
and each button is assigned a command. However, 
some restrictions are applied to the number of display 
colors and shape of the button and therefore the content 
creator cannot freely design the menu screen. 

45 [0239] This problem can be solved by previously 
recording data of the menu screen described in the 
SDAF in a conventional DVD-Audio disk, and displaying 
the menu screen using this data at playback. More spe- 
ctficalty, multimedia contents described In the SDAF and 

50 a CEL redirector for referring from the SDAF to the orig- 
inal DVD-Audio contents. Hereinafter, a DVD-Audio disk 
with such data recorded thereon is called an extended 
DVD-Audio disk, and a player for playing back the 
extended DVD-Audio disk is called SDAF-compliant 

55 DVD-Audio player. 

[0240] FIG. 40 is a diagram showing an example of 
the CEL red! rectors that con-^ponds to a single DVD- 
Audio disk. Each row indicates the CEL redirector for 



23 



45 

each content included in the original DVD-Audio disic. 
The CEL redirector includes a CELJD 2201 , file nanne 
2202. start address 2203, and end address 2204. The 
CELJD 2201 is a content identifier that is unique In the 
disk. The file name 2202 is a name of the file that 5 
includes each content. The start and end addresses 
2203 and 2204 are offset values indicating the start 
location and end location, respectively, from each con- 
tent in the file. The CEL redirector is recorded in a file 
named DVDA.MAP. for example, in an SDAF directory w 
provided in the ROM area of the extended DVD-Audio 
disk. 

[0241] Ail various playback control functions such 
as audio playback order control, slideshow image play- 
back, and a menu function defined by the DVD-Audio is 
standards can be described using the SDAF navigation 
data. For example, the menu function can be realized by 
superimposing JPEG button images having any number 
of colors and shape onto an MPEG-I frame background 
image for display and relating each button region to a 20 
command. 

[0242] When playback control information included 
in the DVD-Audio disk is converted into SDAF naviga- 
tion data, information indicating a content is converted 
into the CELJD by using the CEL redirector. The menu 25 
screen is converted into JPEG button images. The 
obtained images are arranged at locations so as to be 
superimposed onto the background image. The naviga- 
tion data and button images as obtained in the above 
described manner are stored in a single SDAF package, 30 
and recorded in a file named SDAF. S DP, for example, in 
an SDAF directory provided In the ROM region of the 
extended DVD-Audio disk. The method of playing back 
the extended DVD-Audio disk will be described later. 
[0243] Next, an SDAF player for playing back multi- 35 
media contents described with SDAF is described 
below. The SDAF player plays back distributed music 
data in the following manner. First, the player searches 
for the package IDs and navigation information to collect 
the CELJDs of the CELs required for playback. The 40 
player searches purchase database using sets of the 
collected package ID and CEL_ID to determine whether 
each CEL has been purchased or not. If any CEL not 
yet purchased is found, the player analyzes the 
encoded offer, and pays a predetermined price through 45 
the existing electronic distribution system. After pur- 
chasing, the key pair stored in the offer is stored in the 
purchase database. If determining that the SDAF pack- 
age required for playback is not found In the player, the 
player sends out the package ID to the data distribution so 
apparatus. The data distribution apparatus distributes 
an SDAF package with the received package ID to the 
player. After purchasing all CELs required for playback, 
the player decrypts the CEl_s using the key pairs stored 
in the purchase database for playback. At this time, the ss 
player interprets the navigation data for playback con- 
trol. 

[0244] The SDAF title is distributed to the player as 
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being split into one or more SDAF packages. FIGS. 41a 
to 41c are diagrams showing examples how to distribute 
the SDAF packages. In a distribution method as shown 
In FIG. 41a, a package 2301 includes only an audio 
content, while a package 2302 includes only an Image 
or video graphic content Moreover, from the package 
2302, the audio content included in the package 2301 is 
referred to. Therefore, the user who purchased only the 
package 2301 can play back only the audio content. 
The user who purchased the package 2302 in addition 
to the package 2301 can play back the graphic content 
together with the audio content As such, the SDAF title 
may be specified by adding a CEL to the existing track. 
[0245] In a distribution method as shown In FIG. 
41b, a package 2303 includes a plurality of audio con- 
tents and graphic contents. As such, a single package 
may include all CELs Included in the SDAF title. 
[0246] In a distribution method as shown in FIG. 
41c, a single SDAF title is split into packages 2304, 
2305, and 2306 for distribution. The package 2305 
includes a content for Track #1 , while the package 2306 
includes a content for Track #2. In this distribution 
method, it is possible to select either one of the pack- 
ages 2305 and 2306 for distribution. 
[0247] Moreover, in the player, a new SDAF pack- 
age including a content owned by the user may be cre- 
ated. FIGS. 42a to 42c are diagrams showing examples 
how to create SDAF packages. In FIGS. 42a to 42c, a 
user package is an SDAF package created by the user, 
while a purchased package is a distributed SDAF pack- 
age. Contents surrounded by a thick line are owned by 
the user. It is assumed herein that the user owns data 
read from a CD, that is, an audio content ripped from the 
CD, and a graphic content created by himself/herself. 
[0248] As shown in FIG. 42a, the user may create a 
package 2401 including the audio content owned by 
himself/herself. Furthermore, as shown in FIG. 42b, the 
user may create a package 2402 including the audio 
and graphic contents owned by hlnnself/herseif. Still fur- 
ther, as shown in FIG. 42c, the user may create a pack- 
age 2404 from which the audio content included in the 
purchased package 2403 is refen^ed to. If the package 
2404 is played back, the audio content included in the 
purchased package and the graphic content owned by 
the user are played back. Therefore, the image included 
In the purchased package can be changed to the Image 
created by the user, or a new image created by the user 
can be added to the purchased package. 
[0249] Next the SDAF-compliant DVD-Audio player 
for playing back the extended DVD-Audio disk is 
described. The player controls playback operation by 
following the navigation data described with SDAF 
instead of the original playback control information com- 
plying with the DVD-Audio standards. The player reads 
the navigation data and the CEL locator from the 
extended DVD-Audio disk, and operates by following 
the read navigation data. If the original audio content or 
image content is referred to from the navigation data, 
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the player refers to the CEL locator to obtain information 
about the location in which the content is stored, and 
plays back the content. The player reads the back- 
ground image from the DVD-Audio region on the disk 
and the button images from the SDAF data, and com- 
bines them to display the menu screen. 
[0250] As such, with the use of the extended DVD- 
Audio disk, the existing DVD-Audio player can carry out 
conventional playback, while the SDAF-compliant DVD- 
Audio player can display the menu screen by using the 
navigation data described with SDAF. 
[0251] In the above description, the SDAF package 
and CEL redirector are stored in the disk. Atternativety, 
such data may be downloaded through a network to the 
player. This method can be applied to CDs and DVD 
disks that have already been sold to the user. Further- 
more, with this method, the CELs that are accessible 
through a communication network can be referred to by 
using the URL 

[0252] Next, a data conversion apparatus for copy- 
ing multimedia contents specified in SDAF to an exter- 
nal storage medium for portable music players is 
described. Here, the portable music player is structured 
by using semiconductor memory as an external storage 
medium, and characterized by its small size, light 
weight, and capability of writing data therein at high 
speed. The portable music player includes, as shown in 
FIG. 43, a liquid crystal display 2501 capable of display- 
ing text, a control panel 2502 for controlling audio play- 
back, and a headphone 2503 for audio output 
Furthermore, a memory card 2500 for storing audio 
data can be removably attached to the portable music 
player. The portable music player plays back audio con- 
tents complying with MPEG2-AAC, and also displays 
text infomnation. However, the data recording format of 
the memory card is not SDAF, but a unique format 
[0253] FIG. 44 is a block diagram showing the 
structure of the data conversion apparatus for convert- 
ing contents recorded on an extended DVD-Audio disk 
into a predetermined format, and writing the converted 
contents in a memory card for portable music players. In 
FIG. 44, It is assumed that an LPCM-fonnat audio con- 
tent, an Image content in MPEG-I frame format, play- 
back control information described with SDAF, and 
additional text Information are recorded In a disk 2601 . 
[0254] In the data conversion apparatus shown in 
FIG. 44, a data read unit 2602 reads the playback con- 
trol information from the disk 2601, and provides the 
same to a playback control Information analyzing unit 
2603. The playback control information analyzing unit 
2603 analyzes the read playback control information to 
examine whether the content recorded on the disk 2601 
can be played back or requires conversion. 
[0255] Next, the data read unit 2602 sequentially 
reads, from the disk 2601 , contents that can be played 
back by the portable music player, and provides the 
read contents to a data conversion unit 2605. At this 
time, contents that cannot be played back by the porta- 



ble music player Is not read. The data conversion unit 
2605 converts the read contents according to the type 
of a memory card 2500. For example, text information 
that can be directly played back by the portable music 
5 player such as titles is not converted. On the other hand, 
LPCM-format audio contents are converted into 
MPEG2-AAC format so that the portable music player 
can play back the contents. 

[0256] The playback control information conversion 
10 unit 2604 generates playback control Information for the 
portable music player based on the playback control 
information analyzed by the playback control informa- 
tion analyzing unit 2603. A data write unit 2606 writes 
the playback control Infomnation generated by the play- 
15 back control Information conversion unit 2604 and the 
contents converted by the data conversion unit 2605 In 
the memory card 2500. 

[0257] Note that, the data conversion unit shown in 
FIG. 44 may convert arbitrary contents other than audio 

20 contents into a predetermined format and write the con- 
verted contents In the memory card 2500. Furthermore, 
the data recording format of the memory card may be 
an arbitrary format other than SDAF. Still further, for 
supporting a plurality of external storage media, the 

25 data conversion apparatus may include the data conver- 
sion unit, playback control information conversion unit, 
and data write unit for each external storage medium. 
[0258] Moreover, If no navigation data described 
with SDAF is recorded on the disk 2601 , as shown in 

30 FIG. 45, lacking data may be obtained through a com- 
munication network. In FIG. 45, It is assumed that an 
Identification number Is recorded in the disk 2601 . For 
example, the identification number of a music CD is a 
catalog code, ISRC code, and others. 

35 [0259] The data read unit 2602 reads the identifica- 
tion number of the disk, and provides the same to a 
communication unit 2607. The communication unit 
2607 communfcates with a content information server 
261 1 through a communteatlon network 261 0. The com- 

40 munication unit 2607 may access to the content infor- 
mation server 261 1 through the Intemet, or may directly 
access the content Information server 261 1 through a 
telephone circuit The content information server 261 1 
stores the lacking data in relation to the identification 

45 number, and in response to a request from a data con- 
version apparatus, sends the lacking data to the data 
conversion apparatus. After receiving the lacking data, 
the data conversion apparatus carries out the same 
operation as the data conversion apparatus as shown in 

50 FIG. 44. 

[0260] As stated above, the content distribution for- 
mat SDAF according to the present embodiment is a 
format for describing multimedia contents, and mainly 
used for music data distribution. Also, using the SDAF in 
55 combination with the existing music data can extend the 
function of the existing music data. 
[0261] Note that, the correlation between the super 
distribution data described In the first and second 
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embodiments and the SDAF according to the present 
embodiment is as follows. That is, the additional infor- 
mation including reproduction control information as to 
the image data and audio data In the second embodi- 
ment corresponds to the navigation data 2012 shown in 5 
FIG. 18. TTie content 205 or audio data 204 shown in 
FIG. 2 and the image data in the second embodiment 
correspond to the CEL 2013 shown in FIG. 18. The right 
management information 203 shown in FIG. 2 corre- 
sponds to the offer 2014 shown in FIG. 18. w 
[0262] While the invention has been described in 
detail, the foregoing description is in all aspects illustra- 
tive and not restrictive. It is understood that numerous 
other modifications and variations can be devised with- 
out departing from the scope of the invention. is 

Claims 

1 . A digital data copyright protection system for charg- 
ing a user appropriate royalties while protecting a 20 
copyright of digital data, the system comprising: 



when the super distribution data subjected to 
the billing processing is provided with said dis- 
tributor ID, said billing processing unit (103) 
goes through a bonus processing with respect 
to a user identified by the distributor ID. 

2. A digital data recording and reproducing apparatus 
(1011) being capable of storing super distribution 
data including a content which is digital data 
encrypted under a first system and right manage- 
ment information having a content key used for said 
first system, and of reproducing said content after 
going through a purchase processing to be ready 
for a billing processing by communicating with a bill- 
ing processing unit (1 03) connected via a network 
(104). the apparatus comprising: 

super distribution data receiving means (401) 
operable to externally receive said super distri- 
bution data; 

super distribution data storage means (402) 
operable to store said super distribution data; 
purchase processing means (412) operable to 
go through, In response to a user's instruction, 
said purchase processing to reproduce the 
content included in the super distribution data 
stored in said super distribution data storage 
means (402); 

data accessing means (410) operable to 
extract said super distribution data from said 
super distribution data storage means (402); 
content decrypting means (414) operable to 
decrypt, when said purchase processing is car- 
ried out, the super distribution data stored in 
said super distribution data storage means 
(402) under said first system, and extract said 
content; 

reproduction means (415 and 416) operable to 
reproduce the content extracted by said con- 
tent decrypting means (41 4); and 
distributor ID adding means (411) operable to 
encrypt a first user ID which is identification 
information unique to the apparatus, and add 
the encrypted first user ID to the super distribu- 
tion data extracted by said data accessing 
means (410) for external output. 

3. The digital data recording and reproducing appara- 
tus according to claim 2; wherein said right man- 
agement information is also encrypted under a 
second system, and 

a right management information key used for 
said second system is stored in a secured 
region where no user is accessible in a normal 
manner. 

4. The digital data recording and reproducing appara- 



a content distribution unit (1 02) operable to dis- 
tribute super distribution data including said 
digital data over a network (1 04): 25 
a plurality of digital data recording and repro- 
ducing apparatuses (1011, 1012, and 1013) 
interconnected via said network (104), each 
capable of storing the super distribution data 
received from said content distribution unit 30 
(1 02), reproducing said digital data, and distrib- 
uting said super distribution data stored therein 
to the others; and 

a billing processing unit (103) operable to com- 
municate with said digital data recording and 35 
reproducing apparatuses (1011, 1012. and 
1013) over said network (104), and go through 
a billing processing for charging said royalties, 
wherein 

said digital data recording and reproducing 40 
apparatuses (1011. 1012, and 1013) each 

communicate, prior to reproducing said 
digital data, with said billing processing 
unit (103) to go through a purchase 45 
processing to be ready for said billing 
processing when receiving the super distri- 
bution data from said content distribution 
unit (1 02) or the other digital data record- 
ing and reproducing apparatuses over said so 
network (1 04). and 

add, prior to distribution, a distributor ID to 
the super distribution data received from 
said content distribution unit (102) or the 
other digital data recording and reproduc- ss 
ing apparatuses over said network (1 04), 
wherein. 
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tus (1011) according to claim 2, wherein said dis- 
tributor ID adding means (41 1) comprises: 

management information acquiring means 
(504) operable to acquire a state of purchase 5 
indicating whether or not the purchase 
processing has been carried out by said pur- 
chase processing means (412); 
user ID acquiring means (501) operable to 
acquire said first user ID stored in a secured io 
region where no user is accessible in a nonmal 
manner. 

user ID encrypting means (502) operable to 
add. to the first user ID acquired by said user ID 
acquiring means (501), the state of purchase is 
acquired by. said management information 
acquiring means (504) for encryption under a 
predetermined system; and 
user ID adding means (503) operable to add 
the first user ID encrypted by said user ID 20 
encrypting means (502) to the super distribu- 
tion data extracted by said data accessing 
means (41 0). 

5. The digital data recording and reproducing appara- 25 
tus (1011) according to claim 2, wherein said pur- 
chase processing means (412) comprises: 

billing control information extracting means 

(602) operable to extract billing control informa- 30 
tion from the super distribution data extracted 

by said data accessing means (41 0); 
distributor ID extracting means (603) operable 
to extract a second user ID if included in the 
super distribution data extracted by said data 35 
accessing means (41 0); 
billing processing infomnation generating 
means (604) operable to add. if any second 
user ID is extracted by said distributor ID 
extracting means (602). said second user ID to 40 
the billing control information extracted by said 
billing control information extracting means 

(603) . and generate billing processing informa- 
tion; 

billing processing information transmitting 45 
means (605) operable to transmit the billing 
processing information generated by said bill- 
ing processing information generating means 

(604) to the billing processing unit (1 03), which 

is externally provided; and so 
transmitter ID transmitting means (606) opera- 
ble to transmit said first user ID as the transmit- 
ter ID to the externally provided billing 
processing unit (103). 

55 

6. The digital data recording and reproducing appara- 
tus ( 1 0 1 1 ) according to claim 2. further comprising: 



data reading means (406) operable to read a 
content which Is unencrypted digital data; 
right management infomnation acquiring 
means (403) operable to acquire right manage- 
ment information having the content key for 
encrypting the content read by said data read- 
ing means (406); 

content l<ey extracting means (405) operable to 
extract said content key from the rigiit manage- 
ment information acquired by said right man- 
agement Information acquiring means (403); 
data encrypting means (408) operable to 
encrypt said content under said first system 
with the content key extracted by said content 
key extracting means (405); and 
right management information adding means 
(409) operable to add the corresponding right 
management information to the content 
encrypted by said data encrypting means (408) 
for storage in said super distribution data stor- 
age means (402). 

7. The digital data recording and reproducing appara- 
tus (1 01 1 ) according to claim 6. further comprising 
data compressing means (407) operable to com- 
press the content read by said data reading means 
(406) in a predetermined manner, and input the 
compressed content into said data encrypting 
means (408). 

8. The digital data recording and reproducing appara- 
tus (101 1) according to claim 6. further comprising 
additional information storage means (1703) opera- 
ble to store content reproduction control information 
Including information as to control content repro- 
duction and image data added as content; and 

data adding means (1 702) operable to add said 
content reproduction infonnation and said 
image data stored in said additional information 
storage means (1703) to the con-esponding 
content for output to said data encrypting 
means (408). 

9. A billing processing unit (103) operable to store 
super distribution data, and from a digital data 
recording and reproducing apparatus (1011, 1012, 
or 1013) capable of reproducing a content after a 
billing processing, receive, over a network(104), 
billing control information con-esponding to said 
super distribution data, a distributor ID indicating 
who has distributed said super distribution data, 
and a transmitter ID corresponding to said digital 
data recording and reproducing apparatus (1011, 
1012, or 1013), the billing processing unit compris- 
ing: 

billing processing information receiving means 
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54 



(802) operable to receiving said billing control 
information and said distributor ID; 
transmitter authorizing means (803) operable 
to receive said transmitter ID and identify a 
transmitter; ^ 
billing processing means (804) operable to 
can7 out, according to the billing control infor- 
mation received by said billing processing infor- 
mation receiving means (802), the billing 
processing with respect to the transmitter iden- to 
tified by said transmitter authorizing means 

(803) ; and 

bonus processing means (808) operable to 
carry out a bonus processing for a distributor 
identified by the distributor ID received by said is 
billing processing information receiving means 
(802). 

10. A digital data recording and reproducing method of 
storing super distribution data including a content 20 
which is digital data encrypted under a first system 
and right management information having a content 
Jtey used for said first system, and of reproducing 
said content after a billing processing, the method 
comprising: ^ 

a super distribution data receiving step of 
externally receiving said super distribution 
data; 

a purchase processing step of carrying out the 30 
billing processing to reproduce the content 
Included in said super distribution data, 
responding to a user's instruction; 
a content decrypting step of, when the billing 
processing is carried out in said purchase 35 
processing step, decrypting said super distribu- 
tion data under said first system, and extracting 
said content; 

a reproducing step of reproducing the content 
extracted in said content decrypting step; and 40 
a distributor ID adding step of adding, respond- 
ing to the user's instruction, a first user ID 
which is unique identification infomnation to 
said super distribution data for output. 

11. A computer readable/writable recording medium 
being recorded a program to be executed on a com- 
puter system capable of storing super distribution 
data including a content which is digital data 
encrypted under a first system and right manage- a 
ment information having a content key used for said 
first system, and of reproducing said content after a 
billing processing, the program achieving a method 
comprising: ^ 

a super distribution data receiving step of 
externally receiving said super distribution 
data; 



a purchase processing step of carrying out the 
billing processing to reproduce the content 
included in said super distribution data 
responding to a user's instruction; 
a content decrypting step of, when the billing 
processing is can-led out in said purchase 
processing step, decrypting said super distribu- 
tion data under said first system, and extracting 
said content; 

a reproducing step of reproducing the content 
extracted in said content decrypting step; and 
a distributor ID adding step of encrypting a first 
user ID which is unique identification informa- 
tion, and adding the first user ID to said super 
distribution data for output. 
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typedef struct SDAF_ATTR_GRAPHIC_PROPS 
{ 

enum { TAG_ID = 0x0001 } ; 
SDAF_Am width; 
SDAF_ATTR height: 
SDAF_ATTR bitDepth: 
) SDAF_AnR_GRAPHIC_PROPS; 

typedef struct SDAF_ATTR_GRAPHIC_CODEC ; 
{ 

enum { TAG_1D = 0x0002 } ; 
SDAF_ATTR codec: // Q: JPEG, etc 

SDAF_ATTR compression: // 0: RLE, 1:LZW, etc 
» SDAF.ATTR GRAPHIC CODEC; 
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FIG. 3 0 
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